Issue with ROWID

There is an quite old app that runs in Forms 3.0.
Currently it runs on Oracle 7. but it is decided to migrate DB to Oracle 10.2. I know it is not supported combination.
We have migrated data, retargeted forms and tested.
Most of forms work well.
However some forms issue ORA-01410 Wrong ROWID.
We traced them in Oracle and found that some forms issue "select for update" queries:
"SELECT A,B,C FROM TBL WHERE ROWID=:0001 FOR UPDATE A,B,C NOWAIT"
The issue is that the bind variable :0001 is VARCHAR type, not ROWID type.
In this case BLOCK.ROWID is converted to string value of old format 'XXXX.XXX.XXXXX' that Oracle does not like in WHERE clause. Other SQLs that use binds of ROWID type work well.
It is interesting that some forms issue such queries, some do not.
I tried to find the query in .INP files - it is not there.
The erro happens when Forms issues COMMIT_FORM, so I suppose that it is Forms itself, not the App, generates these SQLs and bind vars.
Is my assumption correct?
Is there any way to make Forms to use ROWID type for such binds? May be by using some keys, or by defining invisible field ROWID of type rowid?
Or is it possible to customize locking SQL statement in ON-LOCK trigger?
Or may be it will be more safe to migrate forms to v.4.5?
Any ideas are welcome.
thanks.

Mark Malakanov (user11181920) wrote:
There is an quite old app that runs in Forms 3.0.
Currently it runs on Oracle 7. but it is decided to migrate DB to Oracle 10.2. I know it is not supported combination.
We have migrated data, retargeted forms and tested.
Most of forms work well.
However some forms issue ORA-01410 Wrong ROWID.
We traced them in Oracle and found that some forms issue "select for update" queries:
"SELECT A,B,C FROM TBL WHERE ROWID=:0001 FOR UPDATE A,B,C NOWAIT"
The issue is that the bind variable :0001 is VARCHAR type, not ROWID type.
In this case BLOCK.ROWID is converted to string value of old format 'XXXX.XXX.XXXXX' that Oracle does not like in WHERE clause. Other SQLs that use binds of ROWID type work well.
It is interesting that some forms issue such queries, some do not.
I tried to find the query in .INP files - it is not there.
The erro happens when Forms issues COMMIT_FORM, so I suppose that it is Forms itself, not the App, generates these SQLs and bind vars.
Is my assumption correct?
Is there any way to make Forms to use ROWID type for such binds? May be by using some keys, or by defining invisible field ROWID of type rowid?
Or is it possible to customize locking SQL statement in ON-LOCK trigger?
Or may be it will be more safe to migrate forms to v.4.5?
Any ideas are welcome.
thanks.try to upgrade to latest supported version. I think there is no other issue you have.
hope this helps
Hamid

Similar Messages

Issue with ROWID datatype

Hi,
I am moving 3 columns from source view into oracle target table....one of the column in the source view is "ROW_VALUE" with data type ROWID(this rows contains rowid of the table used in view)
when i map these 3 columns from source view to oracle table , my ROW_VALUE's (eg. AAAT16AAHAAACCfAAB) in changing into oracle.sql.rowid@aecfbi in the target table....
why is the value AAAT16AAHAAACCfAAB chaging when moved to target table
Thanks

Are you talking about the pseudo column ROWID which stores the "address of the row" in the database. Untill and unless you change the column name in the target I dont think so the "Value" itself in the source will get stored as it is an address and will automatically change depending on the target table.

Table with RowID

Hi,
JDeveloper 11g.
I have two tables one with a proper primary key and other one with rowid. I have observed that table with database primary key is loading very fast where as table with RowID is taking time to load.
Is there any issue with RowID? If so, what would be the solution. Please help.
Thanks.

Hi,
should not be a reason. However, having tables without a primary key sound strange to me.
You don't provide much information about how you access and display data queried from the table. This is unfortunate as it prevents any better answer than what I gave.
Frank

Performance issues with version enable partitioned tables?

Hi all,
Are there any known performance issues with version enable partitioned tables?
Ive been doing some performance testes with a large version enable partitioned table and it seems that OCB optimiser is choosing very expensive plans during merge operations.
Tanks in advance,
Vitor
Example:
     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
UPDATE STATEMENT Optimizer Mode=CHOOSE          1          249
UPDATE     SIG.SIG_QUA_IMG_LT
NESTED LOOPS SEMI          1     266     249
PARTITION RANGE ALL                                   1     9
TABLE ACCESS FULL     SIG.SIG_QUA_IMG_LT     1     259     2               1     9
VIEW     SYS.VW_NSO_1     1     7     247
NESTED LOOPS          1     739     247
NESTED LOOPS          1     677     247
NESTED LOOPS          1     412     246
NESTED LOOPS          1     114     244
INDEX RANGE SCAN     WMSYS.MODIFIED_TABLES_PK     1     62     2
INDEX RANGE SCAN     SIG.QIM_PK     1     52     243
TABLE ACCESS BY GLOBAL INDEX ROWID     SIG.SIG_QUA_IMG_LT     1     298     2               ROWID     ROW L
INDEX RANGE SCAN     SIG.SIG_QUA_IMG_PKI$     1          1
INDEX RANGE SCAN     WMSYS.WM$NEXTVER_TABLE_NV_INDX     1     265     1
INDEX UNIQUE SCAN     WMSYS.MODIFIED_TABLES_PK     1     62
/* Formatted on 2004/04/19 18:57 (Formatter Plus v4.8.0) */
UPDATE /*+ USE_NL(Z1) ROWID(Z1) */sig.sig_qua_img_lt z1
SET z1.nextver =
SYS.ltutil.subsversion
(z1.nextver,
SYS.ltutil.getcontainedverinrange (z1.nextver,
'SIG.SIG_QUA_IMG',
'NpCyPCX3dkOAHSuBMjGioQ==',
4574,
4575
4574
WHERE z1.ROWID IN (
(SELECT /*+ ORDERED USE_NL(T1) USE_NL(T2) USE_NL(J2) USE_NL(J3)
INDEX(T1 QIM_PK) INDEX(T2 SIG_QUA_IMG_PKI$)
INDEX(J2 WM$NEXTVER_TABLE_NV_INDX) INDEX(J3 MODIFIED_TABLES_PK) */
t2.ROWID
FROM (SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j1,
sig.sig_qua_img_lt t1,
sig.sig_qua_img_lt t2,
wmsys.wm$nextver_table j2,
(SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j3
WHERE t1.VERSION = j1.VERSION
AND t1.ima_id = t2.ima_id
AND t1.qim_inf_esq_x_tile = t2.qim_inf_esq_x_tile
AND t1.qim_inf_esq_y_tile = t2.qim_inf_esq_y_tile
AND t2.nextver != '-1'
AND t2.nextver = j2.next_vers
AND j2.VERSION = j3.VERSION))

Hello Vitor,
There are currently no known issues with version enabled tables that are partitioned. The merge operation may need to access all of the partitions of a table depending on the data that needs to be moved/copied from the child to the parent. This is the reason for the 'Partition Range All' step in the plan that you provided. The majority of the remaining steps are due to the hints that have been added, since this plan has provided the best performance for us in the past for this particular statement. If this is not the case for you, and you feel that another plan would yield better performance, then please let me know and I will take a look at it.
One suggestion would be to make sure that the table was been recently analyzed so that the optimizer has the most current data about the table.
Performance issues are very hard to fix without a reproducible test case, so it may be advisable to file a TAR if you continue to have significant performance issues with the mergeWorkspace operation.
Thank You,
Ben

Issue with "read by other session" and a parallel MERGE query

Hi everyone,
we have run into an issue with a batch process updating a large table (12 million rows / a few GB, so it's not that large). The process is quite simple - load the 'increment' from a file into a working table (INCREMENT_TABLE) and apply it to the main table using a MERGE. The increment is rather small (usually less than 10k rows), but the MERGE runs for hours (literally) although the execution plan seems quite reasonable (can post it tomorrow, if needed).
The first thing we've checked is AWR report, and we've noticed this:
Top 5 Timed Foreground Events
Event     Waits     Time(s)     Avg wait (ms)     % DB time     Wait Class
DB CPU           10,086           43.82
read by other session     3,968,673     9,179     2     39.88     User I/O
db file scattered read     1,058,889     2,307     2     10.02     User I/O
db file sequential read     408,499     600     1     2.61     User I/O
direct path read     132,430     459     3     1.99     User I/OSo obviously most of the time was consumed by "read by other session" wait event. There were no other queries running at the server, so in this case "other session" actually means "parallel processes" used to execute the same query. The main table (the one that's updated by the batch process) has "PARALLEL DEGREE 4" so Oracle spawns 4 processes.
I'm not sure how to fix this. I've read a lot of details about "read by other session" but I'm not sure it's the root cause - in the end, when two processes read the same block, it's quite natural that only one does the physical I/O while the other waits. What really seems suspicious is the number of waits - 4 million waits means 4 million blocks, 8kB each. That's about 32GB - the table has about 4GB, and there are less than 10k rows updated. So 32 GB is a bit overkill (OK, there are indexes etc. but still, that's 8x the size of the table).
So I'm thinking that the buffer cache is too small - one process reads the data into cache, then it's removed and read again. And again ...
One of the recommendations I've read was to increase the PCTFREE, to eliminate 'hot blocks' - but wouldn't that make the problem even worse (more blocks to read and keep in the cache)? Or am I completely wrong?
The database is 11gR2, the buffer cache is about 4GB. The storage is a SAN (but I don't think this is the bottleneck - according to the iostat results it performs much better in case of other batch jobs).

OK, so a bit more details - we've managed to significantly decrease the estimated cost and runtime. All we had to do was a small change in the SQL - instead of
MERGE /*+ parallel(D DEFAULT)*/ INTO T_NOTUNIFIED_CLIENT D /*+ append */
USING (SELECT
      FROM TMP_SODW_BB) S
ON (D.NCLIENT_KEY = S.NCLIENT_KEY AND D.CURRENT_RECORD = 'Y' AND S.DIFF_FLAG IN ('U', 'D'))
...(which is the query listed above) we have done this
MERGE /*+ parallel(D DEFAULT)*/ INTO T_NOTUNIFIED_CLIENT D /*+ append */
USING (SELECT
      FROM TMP_SODW_BB AND DIFF_FLAG IN ('U', 'D')) S
ON (D.NCLIENT_KEY = S.NCLIENT_KEY AND D.CURRENT_RECORD = 'Y')
...i.e. we have moved the condition from the MERGE ON clause to the SELECT. And suddenly, the execution plan is this
OPERATION                           OBJECT_NAME             OPTIONS             COST
MERGE STATEMENT                                                                 239
MERGE                             T_NOTUNIFIED_CLIENT
    PX COORDINATOR
      PX SEND                       :TQ10000                QC (RANDOM)         239
        VIEW
          NESTED LOOPS                                      OUTER               239
            PX BLOCK                                        ITERATOR
              TABLE ACCESS          TMP_SODW_BB             FULL                2
                Filter Predicates
                  OR
                    DIFF_FLAG='D'
                    DIFF_FLAG='U'
              TABLE ACCESS          T_NOTUNIFIED_CLIENT       BY INDEX ROWID    3
                INDEX               AK_UQ_NOTUNIF_T_NOTUNI    RANGE SCAN        2
                  Access Predicates
                    AND
                      D.NCLIENT_KEY(+)=NCLIENT_KEY
                      D.CURRENT_RECORD(+)='Y'
                  Filter Predicates
                    D.CURRENT_RECORD(+)='Y' Yes, I know the queries are not exactly the same - but we can fix that. The point is that the TMP_SODW_BB table contains 1639 rows in total, and 284 of them match the moved 'IN' condition. Even if we remove the condition altogether (i.e. 1639 rows have to be merged), the execution plan does not change (the cost increases to about 1300, which is proportional to the number of rows).
But with the original IN condition (that turns into an OR combination of predicates) in the MERGE ON clausule, the cost suddenly skyrockets to 990.000 and it's damn slow. It seems like a problem with cost estimation, because once we remove one of the values (so there's only one value in the IN clausule), it works fine again. So I guess it's a planner/estimator issue ...

Reponse time issue with a simple qurey .

hi all,
i started facing a strange issue with the below query form the biging of the month. we have a DW system for a banking domain and in that our accounts table from the first of this month is taking a huge amount of time to retive the data. if i query a back dated data say 31st of may that would be '310509' it give the result in less that 5 seconds. this is a very simple query which i am joing with a transaction table.
i assume the reason for the change in query reponce time is may be tha data from the beging of this month had a datablock extantion and this block is corrupted . kindly let me know what i am thinking is correct or there is another reaosn for this.
Also let me know what resolution should i take to resolve this issue.
my database version is Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
Thanks in advance
SELECT * FROM
(select * from gtxn_dtl_v1 where batch_id='070609') a,
(select * from gacc_dtl_v1 where batch_id='070609') b
WHERE a.account_number = b.id
SELECT * FROM
(select * from gtxn_dtl_v1 where batch_id='310509') a,
(select * from gacc_dtl_v1 where batch_id='310509') b
WHERE a.account_number = b.id

Hemant K Chitale wrote:
I don't think that it is a simple query.
The two objects "gtxn_dtl_v1" and "gacc_dtl_v1" seem to be Views. So, the queries are probably involving joins of other tables.
Without an Execution Plan and information about table and index definitions and statistics on the tables and indexes, any attempt to answer your question would be meaningless.Both are tables. Explain plan is shown below:
SQL> explain plan for
2 SELECT * FROM
3 (select * from gtxn_dtl_v1 where batch_id='070609') a,
4 (select * from gacc_dtl_v1 where batch_id='070609') b
5   WHERE a.account_number = b.id;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4236620027
| Id | Operation                    | Name        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |             |     1 |   601 |    38   (0)| 00:00:01 |
|   1 | NESTED LOOPS                |             |     1 |   601 |    38   (0)| 00:00:01 |
|* 2 |   TABLE ACCESS BY INDEX ROWID| GACC_DTL_V1 |     1 |   313 |     4   (0)| 00:00:01 |
|* 3 |    INDEX RANGE SCAN          | IDX_ACC2_V1 |     1 |       |     3   (0)| 00:00:01 |
|* 4 |   TABLE ACCESS BY INDEX ROWID| GTXN_DTL_V1 |     1 |   288 |    34   (0)| 00:00:01 |
|* 5 |    INDEX RANGE SCAN          | IDX_TXN2_V1 |    55 |       |     8   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("BATCH_ID"='070609')
   3 - access(SUBSTR("BATCH_ID",1,6)='070609')
   4 - filter("BATCH_ID"='070609' AND SUBSTR("GTXN_DTL_V1"."BATCH_ID",1,6)='070609')
   5 - access("GTXN_DTL_V1"."ACCOUNT_NUMBER"="GACC_DTL_V1"."ID")
       filter(SUBSTR("GTXN_DTL_V1"."ACCOUNT_NUMBER",1,3)=SUBSTR("GACC_DTL_V1"."ID",1
              ,3))
22 rows selected.
SQL> explain plan for
2 SELECT * FROM
3 (select * from gtxn_dtl_v1 where batch_id='310509') a,
4 (select * from gacc_dtl_v1 where batch_id='310509') b
5 WHERE a.account_number = b.id;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1249675553
| Id | Operation                     | Name            | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                 |     1 |   601 |   785   (1)| 00:00:10 |
|   1 | TABLE ACCESS BY INDEX ROWID | GACC_DTL_V1     |     1 |   313 |     4   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                |                 |     1 |   601 |   785   (1)| 00:00:10 |
|   3 |    TABLE ACCESS BY INDEX ROWID| GTXN_DTL_V1     |   104 | 29952 |   368   (2)| 00:00:05 |
|* 4 |     INDEX RANGE SCAN          | IDX_TXN1        |   104 |       |   340   (2)| 00:00:05 |
|* 5 |    INDEX RANGE SCAN           | GACC_DTL_V1_IDX |     1 |       |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - access("BATCH_ID"='310509')
       filter(SUBSTR("GTXN_DTL_V1"."BATCH_ID",1,6)='310509')
   5 - access("GTXN_DTL_V1"."ACCOUNT_NUMBER"="GACC_DTL_V1"."ID" AND "BATCH_ID"='310509')
       filter(SUBSTR("GACC_DTL_V1"."BATCH_ID",1,6)='310509' AND
              SUBSTR("GTXN_DTL_V1"."ACCOUNT_NUMBER",1,3)=SUBSTR("GACC_DTL_V1"."ID",1,3))
21 rows selected.
Indexes:
select i.index_name,index_type,i.table_name,num_rows,column_name,COLUMN_EXPRESSION
from all_indexes i,all_ind_columns c,ALL_IND_EXPRESSIONS e
where i.table_name in ('GACC_DTL_V1','GTXN_DTL_V')
and i.index_name = c.index_name
and e.index_name(+) = i.index_name;
INDEX_NAME     INDEX_TYPE          TABLE_NAME     NUM_ROWS     COLUMN_NAME     COLUMN_EXPRESSION
GACC_DTL_V1_IDX     NORMAL               GACC_DTL_V1     57190895     ID
GACC_DTL_V1_IDX     NORMAL               GACC_DTL_V1     57190895     BATCH_ID
IDX_ACC5_V1     NORMAL               GACC_DTL_V1     34524304     POSTING_RESTRICT
IDX_ACC1_V1     NORMAL               GACC_DTL_V1     55919578     CATEGORY
IDX_CUS5_V1     NORMAL               GACC_DTL_V1     54461378     CUSTOMER_NUMBER
IDX_CUS6_V1     NORMAL               GACC_DTL_V1     3272052     LIMIT_REF
IDX_ACC3_V1     FUNCTION-BASED NORMAL     GACC_DTL_V1     52940894     SYS_NC00099$     "CUSTOMER_NUMBER"||'.'||"LIMIT_REF"
IDX_ACC4_V1     FUNCTION-BASED NORMAL     GACC_DTL_V1     57238600     SYS_NC00100$     "CUSTOMER_NUMBER"||'.000'||"LIMIT_REF"
GACC_DTL_V1_IX2     FUNCTION-BASED NORMAL     GACC_DTL_V1     54448627     SYS_NC00101$     SUBSTR("ID",1,3)
IDX_ACC2_V1     FUNCTION-BASED NORMAL     GACC_DTL_V1     55566106     SYS_NC00102$     SUBSTR("BATCH_ID",1,6)Edited by: user577300 on Jun 10, 2009 11:41 PM
So many strange things here:
1.Query showing cost 38 is taking a long time (hours). Other quey takes 5 sec
2. Plans are different.

Performence issue with Update

hi all,
I am facing issue with below update statemetn. taking huge time to update. in xx__TEMP table I have index on Project id column. and all underlying table hase index.
Please look into plan and let me how I can reduce Cost for the blow update statement.
Thanks in advance.
UPDATE dg2.ODS_PROJ_INFO_LOOKUP_TEMP o
SET Months_In_Stage_Cnt =
(SELECT
NVL(ROUND(MONTHS_BETWEEN(SYSDATE,x.project_event_actual_date),2),0) Months_In_Stage_Cnt
FROM od.project_event x
WHERE x.project_id = o.project_id
AND event_category_code = 'G'
AND project_event_seq_nbr =
(SELECT MAX(project_event_seq_nbr)
FROM od.project_event y
WHERE y.project_id = x.project_id
AND y.event_category_code = 'G'
AND y.project_event_actual_date IS NOT NULL
AND stage_nbr <> 0
AND y.project_event_seq_nbr <
(SELECT project_event_seq_nbr
FROM od.project_event z
WHERE stage_nbr =
(SELECT current_stage_nbr
FROM od.project
WHERE project_id = x.project_Id )
AND z.project_id = x.project_Id
AND z.event_category_code = 'G'
AND skip_stage_ind = 'N'
AND project_event_actual_date IS NULL )
Plan
UPDATE STATEMENT CHOOSECost: *1,195,213* Bytes: 71,710,620 Cardinality: 41,213
14 UPDATE DG2.ODS_PROJ_INFO_LOOKUP_TEMP
1 TABLE ACCESS FULL TABLE DG2.ODS_PROJ_INFO_LOOKUP_TEMP Cost: 36 Bytes: 71,710,620 Cardinality: 41,213
13 FILTER
3 TABLE ACCESS BY INDEX ROWID TABLE OD.PROJECT_EVENT Cost: 9 Bytes: 104 Cardinality: 8
2 INDEX RANGE SCAN INDEX (UNIQUE) od.XPKPROJECT_EVENT Cost: 3 Cardinality: 8
12 SORT AGGREGATE Bytes: 16 Cardinality: 1
11 FILTER
5 TABLE ACCESS BY INDEX ROWID TABLE od.PROJECT_EVENT Cost: 9 Bytes: 16 Cardinality: 1
4 INDEX RANGE SCAN INDEX (UNIQUE) od.XPKPROJECT_EVENT Cost: 3 Cardinality: 8
10 FILTER
7 TABLE ACCESS BY INDEX ROWID TABLE od.PROJECT_EVENT Cost: 9 Bytes: 108 Cardinality: 6
6 INDEX RANGE SCAN INDEX (UNIQUE) od.XPKPROJECT_EVENT Cost: 3 Cardinality: 8
9 TABLE ACCESS BY INDEX ROWID TABLE od.PROJECT Cost: 2 Bytes: 9 Cardinality: 1
8 INDEX UNIQUE SCAN INDEX (UNIQUE) od.XPKPROJECT Cost: 1 Cardinality: 1
Thanks
Deb

882134 wrote:
Can any body give me some light why upto Select statement cost is ok, but only Update statemet is take huge 11m costing.
thanks
DebOkay so completely ignore the content of the 2 forum posts.
Why is the cost an issue for you? Without your tables, data and environment, and without a readable execution plan it's difficult to help you.
Maybe you could read the link I gave you and post some of the information it talks about up here.
p.s. read the link.

Create materialized view log with rowid hangs indefinitely..

Hi
create materialized view log on advice_note with rowid;
This stmt hangs indefinitely...
Help needed in resolving this issue
Rp

i have resolved the issue myself.
Found out the sessions that are locking the object , killed all those sessions & pids.
Rp

SQL Query : Order By issue with HUGE Table

Hello friends,
I have been through a terrible issue with order by. I would appreciate your help. Please let me know, your input for my case:
=> if i run select query it returns result quick in some milliseconds. (sql dev. fetches 50 rows at a time)
=> if i run select query with where condition and column (say A) in where condition is even indexed and i have order by and that order by column (say B) is also indexed.
Now, here is the issue:
1. if no. of rows with that where condition can filter yielding small result set then order by works fine .. 1-5 sec which is good.
2.*if no. of rows with that where condition can filter yielding Large result set, say more than 50,000 then with order by then the wait time is exponential.... i have even waited 10+ mins to get the result back for 120,000 records.*
Is order by takes that long for 100K records ... i think something else if wrong... your pointer will really be helpful... i am very new to sql and even newer for large table case.
I am using SQL Developer Version 2.1.1.64
and Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
Thank you so much.
Edited by: 896719 on Jan 11, 2013 8:38 AM

Yes you are correct, but my concentration was on order by thing, so it will do full scan of table so i was putting that ... and was also wondering if millions of record in table should not be a issue...???
Any way for the explain plan , when just a value in the where changes there is the huge difference i want to point out too as below:
SELECT
FROM
    EES_EVT EES_EVT where APLC_EVT_CD= 'ABC' ORDER BY CRE_DTTM DESC
execution time : 0.047 sec
Plan hash value: 290548126
| Id | Operation                    | Name        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |             |    27 | 14688 |    25   (4)| 00:00:01 |
|   1 | SORT ORDER BY               |             |    27 | 14688 |    25   (4)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| EES_EVT     |    27 | 14688 |    24   (0)| 00:00:01 |
|* 3 |    INDEX RANGE SCAN          | XIE1EES_EVT |    27 |       |     4   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("APLC_EVT_CD"='ABC')
Note
   - SQL plan baseline "SYS_SQL_PLAN_6d41e6b91925c463" used for this statement
=============================================================================================
SELECT
FROM
    EES_EVT EES_EVT where APLC_EVT_CD= 'XYZ' ORDER BY CRE_DTTM DESC
execution : 898.672 sec.
Plan hash value: 290548126
| Id | Operation                    | Name        | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |             |   121K|    62M|       |   102K (1)| 00:11:02 |
|   1 | SORT ORDER BY               |             |   121K|    62M|    72M|   102K (1)| 00:11:02 |
|   2 |   TABLE ACCESS BY INDEX ROWID| EES_EVT     |   121K|    62M|       | 88028   (1)| 00:09:27 |
|* 3 |    INDEX RANGE SCAN          | XIE1EES_EVT |   121K|       |       |   689   (1)| 00:00:05 |
Predicate Information (identified by operation id):
   3 - access("APLC_EVT_CD"='XYZ')
Note
   - SQL plan baseline "SYS_SQL_PLAN_ef5709641925c463" used for this statementAlso Note this table contains 74328 MB data in it.
Thanks

Having issues with 9.2.0.5

I have an issue with the following query if I ran in 9.2.0.5 its giving internal error and the fix is in 9.2.0.8 But I can upgrade it immediately is there parameter or any workaround for it
SELECT DISTINCT TABLE0.department_code DEP,
SUM(TABLE1.SALARY)
OVER (PARTITION BY TABLE0.department_code) SAL
FROM DITV1_EMPLOYEE TABLE0,
DITV1_PAYROLL2 TABLE1
WHERE (TABLE0.EMPLOYEE_CODE = TABLE1.EMPLOYEE_CODE)
GROUP BY TABLE0.department_code,
GROUPING SETS((TABLE1.ROWID, TABLE1.SALARY));
Any help would be appeciated.

Can you please help me in changing the code for the following query.
SELECT NVL(TO_CHAR(FIELD0), ' ') FIELD0,
NVL(TO_CHAR(FIELD1), ' ') FIELD1,
NVL(TO_CHAR(FIELD2), ' ') FIELD2,
NVL(TO_CHAR(FIELD3), ' ') FIELD3
FROM (SELECT DISTINCT TABLE0.EMPLID FIELD0,
TABLE1.COST_NUM FIELD1,
SUM(TABLE1.SUISDI_AMT)
OVER (PARTITION BY TABLE0.EMPLID,
TABLE1.COST_NUM) FIELD2,
SUM(TABLE1.CK_GROSS)
OVER (PARTITION BY TABLE0.EMPLID,
TABLE1.COST_NUM) FIELD3
FROM PS_AL_CHK_MEMO TABLE0,
PS_AL_CHK_DATA TABLE1
WHERE (TABLE1.PAYGROUP = TABLE0.PAYGROUP AND TABLE1.FILE_NBR = TABLE0.FILE_NBR AND
TABLE1.CHECK_DT = TABLE0.CHECK_DT AND TABLE1.WEEK_NBR = TABLE0.WEEK_NBR AND
TABLE1.PAYROLL_NBR = TABLE0.PAYROLL_NBR AND TABLE1.CHECK_NBR = TABLE0.CHECK_NBR
AND TABLE1.ENTRY_NBR = TABLE0.ENTRY_NBR)
AND (EXISTS (SELECT 'x'
FROM PS_USER_SCRTY_TBL S
WHERE S.EMPLID = TABLE0.EMPLID
AND S.EMPL_RCD_NBR = TABLE0.EMPL_RCD_NBR
AND S.OPRID = '')
AND EXISTS (SELECT 'x'
FROM PS_USER_SCRTY_TBL S
WHERE S.EMPLID = TABLE1.EMPLID
AND S.EMPL_RCD_NBR = TABLE1.EMPL_RCD_NBR
AND S.OPRID = ''))
GROUP BY TABLE0.EMPLID,
TABLE1.COST_NUM,
GROUPING SETS ((TABLE1.ROWID,
TABLE1.SUISDI_AMT),
(TABLE1.ROWID,
TABLE1.CK_GROSS))
ORDER BY TABLE0.EMPLID ASC)
WHERE rownum <= 40001

Performance issue with a Custom view

Hi ,
I am pretty new to performance tuning and facing a performance issue with a custom view.
Execution time for view query is good but as soon as I append a where caluse to view query ,the execution time increases.
Below is the view query:
CREATE OR REPLACE XXX_INFO_VIEW AS
SELECT csb.system_id license_id,
cst.name license_number ,
csb.system_type_code license_type ,
csb.attribute3 lac , -- license authorization code
csb.attribute6 lat , -- license admin token
csb.attribute12 ols_reg, -- OLS Registration allowed flag
l.attribute4 license_biz_type ,
NVL (( SELECT 'Y' l_supp_flag
FROM csi_item_instances cii,
okc_k_lines_b a,
okc_k_items c
WHERE c.cle_id = a.id
AND a.lse_id = 9
AND c.jtot_object1_code = 'OKX_CUSTPROD'
AND c.object1_id1 = cii.instance_id||''
AND cii.instance_status_id IN (3, 510)
AND cii.system_id = csb.system_id
AND a.sts_code IN ('SIGNED', 'ACTIVE')
AND NVL (a.date_terminated, a.end_date) > SYSDATE
AND ROWNUM < 2), 'N') active_supp_flag,
hp.party_name "Customer_Name" , -- Customer Name
hca.attribute12 FGE_FLAG,
(SELECT /*+INDEX (oklt OKC_K_LINES_TL_U1) */
nvl(max((decode(name, 'eSupport','2','Enterprise','1','Standard','1','TERM RTU','0','TERM RTS','0','Notfound'))),0) covName --TERM RTU and TERM RTS added as per Vijaya's suggestion APR302013
FROM OKC_K_LINES_B oklb1,
OKC_K_LINES_TL oklt,
OKC_K_LINES_B oklb2,
OKC_K_ITEMS oki,
CSI_item_instances cii
WHERE
OKI.JTOT_OBJECT1_CODE = 'OKX_CUSTPROD'
AND oklb1.id=oklt.id
AND OKI.OBJECT1_ID1 =cii.instance_id||''
AND Oklb1.lse_id=2
AND oklb1.dnz_chr_id=oklb2.dnz_chr_id
AND oklb2.lse_id=9
AND oki.CLE_ID=oklb2.id
AND cii.system_id=csb.system_id
AND oklt.LANGUAGE=USERENV ('LANG')) COVERAGE_TYPE
FROM csi_systems_b csb ,
csi_systems_tl cst ,
hz_cust_accounts hca,
hz_parties hp,
fnd_lookup_values l
WHERE csb.system_type_code = l.lookup_code (+)
AND csb.system_id = cst.system_id
AND hca.cust_account_id =csb.customer_id
AND hca.party_id= hp.party_id
AND cst.language = USERENV ('LANG')
AND l.lookup_type (+) = 'CSI_SYSTEM_TYPE'
AND l.language (+) = USERENV ('LANG')
AND NVL (csb.end_date_active, SYSDATE+1) > SYSDATE)
I have forced an index to avoid Full table scan on OKC_K_LINES_TL and suppressed an index on CSI_item_instances.instance id to make the view query fast.
So when i do select * from XXX_INFO_VIEWit executes in a decent time,But when I try to do
select * from XXX_INFO_VIEW where active_supp_flag='Y' and coverage_type='1'
it takes lot of time.
Execution plan is same for both queries in terms of cost but with WHERE clause Number of bytes increases.
Below are the execution plans:
View query:
SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
     10 COUNT STOPKEY
          9 NESTED LOOPS
               7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1
                    5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299
                         2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155
                              1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                         4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
                              3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                    6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
               8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
     12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1
          11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
     28 SORT AGGREGATE Bytes: 169 Cardinality: 1
          27 NESTED LOOPS
               25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768
                    23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757
                         20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578
                              17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606
                                   14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315
                                        13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                                   16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
                                        15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                              19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
                                   18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
                         22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10
                              21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9
                    24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1
               26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1
     43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
          41 NESTED LOOPS
               39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196
                    37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196
                         32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196
                              30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17
                                   29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
                              31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196
                         36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887
                              35 HASH JOIN
                                   33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
                                   34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
                    38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
               40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1
          42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918
Execution plan for view query with WHERE clause:
SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211
     10 COUNT STOPKEY
          9 NESTED LOOPS
               7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1
                    5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299
                         2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155
                              1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                         4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
                              3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                    6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
               8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
     12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1
          11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
     28 SORT AGGREGATE Bytes: 169 Cardinality: 1
          27 NESTED LOOPS
               25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768
                    23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757
                         20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578
                              17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606
                                   14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315
                                        13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                                   16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
                                        15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                              19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
                                   18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
                         22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10
                              21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9
                    24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1
               26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1
     44 VIEW VIEW APPS.WRS_LICENSE_INFO_V Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211
          43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
               41 NESTED LOOPS
                    39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196
                         37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196
                              32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196
                                   30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17
                                        29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
                                   31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196
                              36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887
                                   35 HASH JOIN
                                        33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
                                        34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
                         38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
                    40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1
               42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918

Hi,
You should always try using primary index fields, if not possible then secondary index fields.
Even if you cannot do anything from either of the two then try this,
Use Less distinct fields on the top.
In your case , you can use bukrs ,gjahr ,werks on the top in the where condition..then followed by less distinct values..
Even when you use secondary index if you have 4 fields in your sec index and you are using only two fields from the top then the index is useful only upto that two fields provided they are in sequence.

Issue with sql performance

Hi, I am experiencing an issue with a couple of sql statements.   The rest of the db seems to be performing optimally.
A little history: Stats typically were never touched on this db and they were old (I mean very very old). However, the database performance was optimal. Recently we ran into an issue (turned out to be hardware), but in the troubleshooting, we deleted the old statistics and refreshed the stats across the board.
Prior to this incident, these queries would finish in mere minutes.
Performance for a few queries is sub optimal now.
When I execute this query it is performing ok returning a values in just over a minute.
select MAX(fr.fee_rqst_sid)
      from fee_rqst fr
      where fr.prcd_dt <= to_date('15/10/2013', 'DD/MM/RRRR');
Elapsed: 00:01:10.17
Plan hash value: 3146244357
| Id | Operation          | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |          |     1 |    23 |   404K (2)| 01:20:49 |
|   1 | SORT AGGREGATE    |          |     1 |    23 |            |          |
|* 2 |   TABLE ACCESS FULL| FEE_RQST |   148M| 3262M|   404K (2)| 01:20:49 |
When it is executed as part of the slightly larger query it belongs to performance drops to over 40 minutes.
    select MAX(ch.clm_hdr_sid)
    from clm_hdr ch
    where ch.fee_rqst_sid <= (
      select MAX(fr.fee_rqst_sid)
      from fee_rqst fr
      where fr.prcd_dt <= to_date('15/10/2013', 'DD/MM/RRRR'));
PLAN_TABLE_OUTPUT
Plan hash value: 2801176651
| Id | Operation                    | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |            |     1 |    12 |   718K (1)| 02:23:41 |
|   1 | SORT AGGREGATE              |            |     1 |    12 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| CLM_HDR    | 9410K|   107M|   718K (1)| 02:23:41 |
|* 3 |    INDEX RANGE SCAN          | IDX$_00002 | 1879K|       | 8533   (1)| 00:01:43 |
|   4 |     SORT AGGREGATE           |            |     1 |    23 |            |          |
|* 5 |      TABLE ACCESS FULL       | FEE_RQST   |   148M| 3262M|   404K (2)| 01:20:49 |
I've create/dropped an index on the date column figuring it might help but it did not as a full table scan still occurred.
The primary key indexes have up to date stats and are not corrupted indexes.
Again this is production and the rest of the db is running optimally and this db is used heavily.
I did run a sqltune but no new results yielded.
GENERAL INFORMATION SECTION
Tuning Task Name   : sql_tuning_task1
Tuning Task Owner : SYS
Workload Type      : Single SQL Statement
Scope              : COMPREHENSIVE
Time Limit(seconds): 60
Completion Status : COMPLETED
Started at         : 04/21/2015 16:23:18
Completed at       : 04/21/2015 16:24:15
Schema Name: SYS
SQL ID     : g52fuy8db7qgb
SQL Text   : select MAX(ch.clm_hdr_sid)
                 from npf.clm_hdr ch
                 where ch.fee_rqst_sid <= (
                   select MAX(fr.fee_rqst_sid)
                   from npf.fee_rqst fr
                   where fr.prcd_dt <= to_date('15/10/2013', 'DD/MM/RRRR'))
There are no recommendations to improve the statement.
Any advice on what else I can check?

Before asking this question, next time you would need to ask this forum to clean their crystal balls.
Your many many lines boil down to:
My car doesn't run, please fix my car, as there is insufficient INFORMATION to work on, and plenty of RIDDLES
1 Your database doesn't seem to have a four digit version
2 Your database doesn't seem to run on an OS
3 The statistics where 'refreshed across the board'. How that happened, this forum needs to guess.
4 Which indices are present on this table, this forum needs to guess
5 Which part of the table satisifies the where clause, this forum needs to guess.
So the obvious would be to answer all of these questions AND run the statement with event 10053 set, so the optimizer decisions are dumped to a trace file,
See https://asktom.oracle.com/pls/asktom/f?p=100:11:0%3A%3A%3A%3AP11_QUESTION_ID:63445044804318
And lastly, I find it more and more annoying, many people don't seem to a have a name, and post 100 percent anonymously.
Sybrand Bakker
Senior Oracle DBA

Issues with Creative Cloud for teams deployment workflow

The Adobe Creative Cloud for teams IT Deployment Guide lists out steps for IT admins to deploy the CS6 applications and then have their end-users license the trial software with their Adobe IDs once they have been invited to the team. There are two major issues with this document.
First, the media that is on the FTP is not for North American English. We are working to get that posted on the FTP site ASAP. In the meantime, you can find the CS6 MC media from: http://www.adobe.com/downloads/
[Note: Getting media from that page requires the use of the Adobe Download Assistant which is very consumer focused. Sorry about that.]
Second, in order to have the ability to login properly with a Creative Cloud for Teams account the system needs to have the latest copy of Adobe Application Manager installed. If you do not do this step the end user will be prompted for a serial number.
Unfortunately the Adobe Application Manager can’t be packaged with AAMEE nor is it a native installer. I know, I know! Here are the links to the Adobe Application Manager installers:
Windows: http://www.adobe.com/support/downloads/detail.jsp?ftpID=4773
Mac: http://www.adobe.com/support/downloads/detail.jsp?ftpID=4774
It can be installed from command line by:
Win: <Path to Setup.exe>Set-up.exe –mode=silent –action=install
Mac: <path to ASU> /ASU/Install.app/Contents/MacOS/Install –mode=silent –action=install
Jody Rodgers | Sr. Product Manager | Creative Cloud for Enterprise | Adobe Systems

Hi Boncker,
I see that you have an active Subscription under your account . Please launch any of the installed product and when you get the trial prompt , please click on License this software and then Enter the Adobe Id & Password for the account that you have accepted the invite .
Please do let us know if that worked for you or not .
Cheers,
Kartikay Sharma

Issue with magsafe/charging (blinks green, amber, off)

Having a quirky issue with my mid-2009 Macbook Pro.
A month or so ago, I began having an issue with my macbook charging. When the computer is up and running and I plug in the magsafe it will say "Calculating..." and then say "Not Charging" and then switch to battery use. It constantly does this as long as the magsafe is connected. The lights on the magsafe will constantly cycle from green to amber to no light.
At first, it would do it a few times then it would start charging. Now it constantly does this without ever stopping. I was editing video the other day for a while and it never stopped the cycle.
Thinking it was the battery, I took it into the Apple Store last week and got a new battery because it had been saying "Service battery" for a while and the battery would only last about 20 minutes on a charge. So I just thought the battery finally refused to charge.
But the problem still exists.
The magsafe is new (only 3 months old) and here's the quirky thing: the computer will charge if it's asleep (lid closed) or shut down completely. No blinking lights at all. It will charge as long as it's asleep or shut down. So I don't think it's the charger. But as soon as you hit the power button to starting booting up, it will blink.
I have reset the SMC a couple times actually, but no change.
Is there something software/firmware related that I haven't tried? Any insight or suggestions would be greatly appreciated before I take it back to the Apple Store (which is about an hour away).
Thanks!

Try resetting the system management controller
http://support.apple.com/kb/HT3964?viewlocale=en_US
If that did nothing for you, try resetting the NVRAM
https://support.apple.com/kb/HT1379

Issue With Page Break When Sorting is also applied on group

Hi
I am facing an issue with Page break only when I have sorting applied on the grouping that I have in the template.
The following is the sample XML
<ROWSET>
<ROW>
<GRE>org1</GRE>
<ORGANIZATION>Accounts</ORGANIZATION>
<FULL_NAME>test1,</FULL_NAME>
<ELEMENT_NAME>TEST BONUS</ELEMENT_NAME>
<CLASSIFICATION>Supplemental Earnings</CLASSIFICATION>
<RUN_VALUE>250</RUN_VALUE>
<MONTH_VALUE>500</MONTH_VALUE>
<QUARTER_VALUE>500</QUARTER_VALUE>
<YEAR_VALUE>500</YEAR_VALUE>
</ROW>
<ROW>
<GRE>org1</GRE>
<ORGANIZATION>Finance</ORGANIZATION>
<FULL_NAME>test2</FULL_NAME>
<ELEMENT_NAME>VOLUNTARY AD AND D</ELEMENT_NAME>
<CLASSIFICATION>Voluntary Deductions</CLASSIFICATION>
<RUN_VALUE>5.19</RUN_VALUE>
<MONTH_VALUE>10.38</MONTH_VALUE>
<QUARTER_VALUE>10.38</QUARTER_VALUE>
<YEAR_VALUE>10.38</YEAR_VALUE>
</ROW>
<ROW>
<GRE>org1</GRE>
<ORGANIZATION>Finance</ORGANIZATION>
<FULL_NAME>test3</FULL_NAME>
<ELEMENT_NAME>HMO MEDICAL</ELEMENT_NAME>
<CLASSIFICATION>Pre-Tax Deductions</CLASSIFICATION>
<RUN_VALUE>19.67</RUN_VALUE>
<MONTH_VALUE>39.34</MONTH_VALUE>
<QUARTER_VALUE>39.34</QUARTER_VALUE>
<YEAR_VALUE>39.34</YEAR_VALUE>
</ROW>
<ROW>
<GRE>org1</GRE>
<ORGANIZATION>Finance</ORGANIZATION>
<FULL_NAME>test4</FULL_NAME>
<ELEMENT_NAME>PENSION NR DC</ELEMENT_NAME>
<CLASSIFICATION>Pre-Tax Deductions</CLASSIFICATION>
<RUN_VALUE>0</RUN_VALUE>
<MONTH_VALUE>360</MONTH_VALUE>
<QUARTER_VALUE>360</QUARTER_VALUE>
<YEAR_VALUE>360</YEAR_VALUE>
</ROW>
</ROWSET>
In the template I group the data based on CLASSIFICATION and then sort on the same column CLASSIFICATION. I have a page-break applied for every group.
When I generate the PDF, I am not getting the page-breaks for every group. Instead some of them are displayed in the same page.
But when I remove the sorting that I had in the template on the column CLASSIFICATION, I am getting the output in the desired way but not in a sorted order.
kumar

Hi All,
I am using MS-WORD 2007 and BI Publisher desktop 10.1.3.3.3.
When I use split-by-page-break, splitting is performed for every line .. but not for group of lines.
Can anybody throw some light on this?
FYI...
I am using this code:
?if: position() mod 6= 0?
?split-by-page-break:?
?end if?
(Of course with in tags)
in G_LINES loop.
Can anybody help me out :-(
--Saritha

Issue with ROWID

Similar Messages

Maybe you are looking for