Select query taking time
THe following query is taking time. Is there anyway better to write this query.
SELECT PROGRAM_NAME_ID ,PROGRAM_NAME,sum(balance)"Unpaid Balance"
FROM (
SELECT DISTINCT
PROGRAM_NAME_ID ,PROGRAM_NAME,
t.billing_key billing_key,
(TUFF_GENERIC_PKG.GET_TOTAL(t.billing_key,t.program_key)+
nvl(PENALTY_INTEREST(t.billing_key,t.program_key,b.company_id,b.report_period ),0))
-PAYMENT_AMOUNT(B.COMPANY_ID,T.PROGRAM_KEY,B.REPORT_PERIOD) Balance,
Report_period,company_id
FROM BILLING B,
PROG_SURCH T ,
mv_program_dict P
WHERE
B.BILLING_KEY=T.BILLING_KEY
AND p.program_key= t.program_key(+)
and company_id=:p3_hide_comp
and b.SUBMIT_STATUS='S'
union
SELECT DISTINCT
PROGRAM_NAME_ID ,PROGRAM_NAME,
t.billing_key billing_key,
(TUFF_GENERIC_PKG.GET_TOTAL(t.billing_key,t.program_key)+
nvl(PENALTY_INTEREST(t.billing_key,t.program_key,b.company_id,b.report_period ),0))
-PAYMENT_AMOUNT(B.COMPANY_ID,T.PROGRAM_KEY,B.REPORT_PERIOD) Balance,
Report_period,company_id
FROM MV_BILLING B,
MV_PROG_SURCH T ,
mv_program_dict P
WHERE
B.BILLING_KEY=T.BILLING_KEY
AND p.program_key= t.program_key(+)
and company_id=:p3_hide_comp
order by report_period,program_name_id )
where balance>=0
GROUP BY PROGRAM_NAME_ID,PROGRAM_NAME
ORDER BY PROGRAM_NAME_ID
Hi,
This is totally right.
>
Being one such call. The price for calling pl/sql functions in SQL can be quite high. I'd highly recommend you find a way to incorporate the pl/sql code into the SQL query.
>
but, try with this query. I hope would help you and return the rows you want.
SELECT program_name_id, program_name,
SUM ( tuff_generic_pkg.get_total (billing_key, program_key)
+ NVL (penalty_interest (billing_key,
program_key,
company_id,
report_period
0
- payment_amount (company_id, program_key, report_period) balance
FROM (SELECT program_name_id, program_name, t.billing_key, t.program_key,
b.company_id, b.report_period
FROM billing b, prog_surch t, mv_program_dict p
WHERE b.billing_key = t.billing_key
AND p.program_key = t.program_key(+)
AND company_id = :p3_hide_comp
AND b.submit_status = 'S'
UNION
SELECT program_name_id, program_name, t.billing_key, t.program_key,
b.company_id, b.report_period report_period, company_id
FROM mv_billing b, mv_prog_surch t, mv_program_dict p
WHERE b.billing_key = t.billing_key
AND p.program_key = t.program_key(+)
AND company_id = :p3_hide_comp) sub
WHERE ( tuff_generic_pkg.get_total (billing_key, program_key)
+ NVL (penalty_interest (billing_key,
program_key,
company_id,
report_period
0
- payment_amount (company_id, program_key, report_period) >= 0
GROUP BY program_name_id, program_nameObviosly I cannot testing.
HTH -- johnxjean --
Similar Messages
-
Select query taking more time..
Hi friends..
The below inner join statement is taking more time , can any body sugget me to improve the performance . I tried FOR ALL ENTRIES also but that also taking more time than inner join statement .
SELECT a~vbeln from vbap as a inner join vakpa as b
on avbeln = bvbeln
into corresponding fields of table IT_VAKPA
where a~WERKS IN S_IWERKS
and a~pstyv NE 'ZRS'
and b~vkorg = IVKORG
and b~audat IN IAUDAT
and b~vtweg IN IVTWEG.
Regards
ChetanHi Chetan ,
VAKPA is an index table. From the select query , it has been observed that you are not fetching any data from VAKPA. Only you have added some selection paramenters in where clause of select query.
My suggestion will be instead of using VAKPA in inner join you use VBAK along with VBAP. All the fields that you are using as selection condition from VAKPA are there in VBAK.
I am sure performance of query will be improved.
If still duo to business logic you need to use VAKPA, try to create secondary non unique index on fields VKORD,AUDATand VTWEG on table VAKPA.
However I will recommend you to go for first option only. If this does not work then go for second option.
Hopfully this will help you.
Regards,
Nikhil -
Hi All,
I am trying to run one SELECT statement which uses 6 tables. That query generally take 25-30 minutes to generate output.
Today it is running from more than 2 hours. I have checked there are no locks on those tables and no other process is using them.
What else I should check in order to figure out why my SELECT statement is taking time?
Any help will be much appreciated.
Thanks!Please let me know if you still want me to provide all the information mentioned in the link.Yes, please.
Before you can even start optimizing, it should be clear what parts of the query are running slow.
The links contains the steps to take regarding how to identify the things that make the query run slow.
Ideally you post a trace/tkprof report with wait events, it'll show on what time is being spent, give an execution plan and a database version all in once...
Today it is running from more than 2 hours. I have checked there are no locks on those tables and no other process is using them.Well, something must have changed.
And you must indentify what exactly has changed, but it's a broad range you have to check:
- it could be outdated table statistics
- it could be data growth or skewness that makes Optimizer choose a wrong plan all of a sudden
- it could be a table that got modified with some bad index
- it could be ...
So, by posting the information in the link, you'll leave less room for guesses from us, so you'll get an explanation that makes sense faster or, while investigating by following the steps in the link, you'll get the explanation yourself. -
Dear all ,
I am fetching data from pool table a006. The select query is mentioned below.
select * from a005 into table i_a005 for all wntries in it_table
where kappl = 'V'
and kschl IN s_kschl
and vkorg in s_vkorg
and vtweg in s_vtgew
and matnr in s_matnr
and knumh = it_table-knumh .
here every fields are primary key fields except one field knumh which is comparing with table it_table. Because of these field this query is taking too much time as KNUMH is not primary key. And a005 is pool table . So , i cant create index for same. If there is alternate solutions , than please let me know..
Thank You ,
And in technical setting of table ITS Metioned as Fully buffered and size category is 0 .. But data are around 9000000. Is it issue or What ? Can somebody tell some genual reason ? Or improvement in my select query.........
Edited by: TVC6784 on Jun 30, 2011 3:31 PMTVC6784 wrote:
Hi Yuri ,
>
> Thanks for your reply....I will check as per your comment...
> bUT if i remove field KNUMH From selection condition and also for all entries in it_itab , than data fetch very fast As KNUMH is not primary key..
> . the example is below
>
> select * from a005 into table i_a005
> where kappl = 'V'
> and kschl IN s_kschl
> and vkorg in s_vkorg
> and vtweg in s_vtgew
> and matnr in s_matnr.
>
> Can you comment anything about it ?
>
> And can you please say how can i check its size as you mention that is 2-3 Mb More ?
>
> Edited by: TVC6784 on Jun 30, 2011 7:37 PM
I cannot see the trace and other information about the table so I cannot judge why the select w/o KNUMH is faster.
Basically, if the table is buffered and it's contents is in the SAP application server memory, the access should be really fast. Does not really matter if it is with KNUMH or without.
I would really like to see at least ST05 trace of your report that is doing this select. This would clarify many things.
You can check the size by multiplying the entries in A005 table by 138. This is (in my test system) the ABAP width of the structure.
If you have 9.000.000 records in A005, then it would take 1,24 Gb in the buffer (which is a clear sign to unbuffer). -
Select query taking too much time to fetch data from pool table a005
Dear all,
I am using 2 pool table a005 and a006 in my program. I am using select query to fetch data from these table. i.e. example is mentioned below.
select * from a005 into table t_a005 for all entries in it_itab
where vkorg in s_vkorg
and matnr in s_matnr
and aplp in s_aplp
and kmunh = it_itab-kmunh.
here i can't create index also as tables are pool table...If there is any solutions , than please help me for same..
Thanks ,it would be helpful to know what other fields are in the internal table you are using for the FOR ALL ENTRIES.
In general, you should code the order of your fields in the select in the same order as they appear in the database. If you do not have the top key field, then the entire database is read. If it's large then it's going to take a lot of time. The more key fields from the beginning of the structure that you can supply at faster the retrieval.
Regards,
Brent -
Select Query taking long time to run second time
Hi All,
I have Oracle 11gR1 in windows server 2008 R2 .
I have some tables with 10 million records . When i run the select query for those tables first time it gives me result in 15 seconds but if i am running the same script second time from the same session I am getting the result in 15 minutes to complete ..
Why it is happening? What may be the solution for this ?
Thanks & Regards,
Vikash jain(Junior DBA)Hi Mohamed,
I just saw that both the times for the same query execution plan is different ..
here are the details :
First time Second Time
g84m3qqjv2p3q g84m3qqjv2p3q
2733045235 1310485984
So plz tell me how should i force database to use the first execution plan ?
I got this script for forcing the Db to use the same execution plan
accept sql_id -
prompt 'Enter value for sql_id: ' -
default 'X0X0X0X0'
accept plan_hash_value -
prompt 'Enter value for plan_hash_value: ' -
default 'X0X0X0X0'
accept fixed -
prompt 'Enter value for fixed (NO): ' -
default 'NO'
accept enabled -
prompt 'Enter value for enabled (YES): ' -
default 'YES'
accept plan_name -
prompt 'Enter value for plan_name (ID_sqlid_planhashvalue): ' -
default 'X0X0X0X0'
set feedback off
set sqlblanklines on
set serveroutput on
declare
l_plan_name varchar2(40);
l_old_plan_name varchar2(40);
l_sql_handle varchar2(40);
ret binary_integer;
l_sql_id varchar2(13);
l_plan_hash_value number;
l_fixed varchar2(3);
l_enabled varchar2(3);
major_release varchar2(3);
minor_release varchar2(3);
begin
select regexp_replace(version,'\..*'), regexp_substr(version,'[0-9]+',1,2) into major_release, minor_release from v$instance;
minor_release := 2;
l_sql_id := '&&sql_id';
l_plan_hash_value := to_number('&&plan_hash_value');
l_fixed := '&&fixed';
l_enabled := '&&enabled';
ret := dbms_spm.load_plans_from_cursor_cache(
sql_id=>l_sql_id,
plan_hash_value=>l_plan_hash_value,
fixed=>l_fixed,
enabled=>l_enabled);
if minor_release = '1' then
-- 11gR1 has a bug that prevents renaming Baselines
dbms_output.put_line(' ');
dbms_output.put_line('Baseline created.');
dbms_output.put_line(' ');
else
-- This statements looks for Baselines create in the last 4 seconds
select sql_handle, plan_name,
decode('&&plan_name','X0X0X0X0','SQLID_'||'&&sql_id'||'_'||'&&plan_hash_value','&&plan_name')
into l_sql_handle, l_old_plan_name, l_plan_name
from dba_sql_plan_baselines spb
where created > sysdate-(1/24/60/15);
ret := dbms_spm.alter_sql_plan_baseline(
sql_handle=>l_sql_handle,
plan_name=>l_old_plan_name,
attribute_name=>'PLAN_NAME',
attribute_value=>l_plan_name);
dbms_output.put_line(' ');
dbms_output.put_line('Baseline '||upper(l_plan_name)||' created.');
dbms_output.put_line(' ');
end if;
end;
undef sql_id
undef plan_hash_value
undef plan_name
undef fixed
set feedback on
Output:
Enter value for sql_id: g84m3qqjv2p3q
Enter value for plan_hash_value: 2733045235
Enter value for fixed (NO):
Enter value for enabled (YES):
Enter value for plan_name (ID_sqlid_planhashvalue): g84m3qqjv2p3q
old 16: l_sql_id := '&&sql_id';
new 16: l_sql_id := 'g84m3qqjv2p3q';
old 17: l_plan_hash_value := to_number('&&plan_hash_value');
new 17: l_plan_hash_value := to_number('2733045235');
old 18: l_fixed := '&&fixed';
new 18: l_fixed := 'NO';
old 19: l_enabled := '&&enabled';
new 19: l_enabled := 'YES';
old 40: decode('&&plan_name','X0X0X0X0','SQLID_'||'&&sql_id'||'_'||'&&plan_hash_value','&&plan_name')
new 40: decode('g84m3qqjv2p3q','X0X0X0X0','SQLID_'||'g84m3qqjv2p3q'||'_'||'2733045235','g84m3qqjv2p3q')
declare
ERROR at line 1:
ORA-01403: no data found
ORA-06512: at line 39
Kindly help me to resolve the issue ..
Thanks & Regards,
Vikash Jain(Junior DBA) -
We have this query which is taking a long time to execute. From the explain plan what i found out is there is a full table scan going on W_GL_OTHER_F. Please help in identifying the problem area and solutions.
The query is,
select D1.c1 as c1,
D1.c2 as c2,
D1.c3 as c3,
D1.c4 as c4,
D1.c5 as c5,
D1.c6 as c6,
D1.c7 as c7,
D1.c8 as c8
from
(select distinct D1.c2 as c1,
D1.c3 as c2,
D1.c4 as c3,
D1.c5 as c4,
D1.c6 as c5,
D1.c7 as c6,
D1.c8 as c7,
D1.c1 as c8,
D1.c5 as c9
from
(select sum(case when T324628.OTHER_DOC_AMT is null then 0 else T324628.OTHER_DOC_AMT end ) as c1,
T91397.GL_ACCOUNT_NUM as c2,
T149255.SEGMENT_VAL_CODE as c3,
T148908.SEGMENT_VAL_DESC as c4,
T148543.HIER4_CODE as c5,
T148543.HIER4_NAME as c6,
T91707.ACCT_DOC_NUM as c7,
T91707.X_LINE_DESCRIPTION as c8
from
W_GL_OTHER_F T91707 /* Fact_W_GL_OTHER_F */ ,
W_GL_ACCOUNT_D T91397 /* Dim_W_GL_ACCOUNT_D */ ,
W_STATUS_D T96094 /* Dim_W_STATUS_D_Generic */ ,
WC_GL_OTHER_F_MV T324628 /* Fact_WC_GL_OTHER_MV */ ,
W_GL_SEGMENT_D T149255 /* Dim_W_GL_SEGMENT_D_Segment1 */ ,
W_GL_SEGMENT_D T148937 /* Dim_W_GL_SEGMENT_D_Segment3 */ ,
W_HIERARCHY_D T148543 /* Dim_W_HIERARCHY_D_Segment3 */ ,
W_GL_SEGMENT_D T148908 /* Dim_W_GL_SEGMENT_D_Segment2 */
where ( T91397.ROW_WID = T91707.GL_ACCOUNT_WID and T91707.DOC_STATUS_WID = T96094.ROW_WID and T96094.ROW_WID = T324628.DOC_STATUS_WID and T148543.HIER_CODE = T148937.SEGMENT_LOV_ID and T148543.HIER20_CODE = T148937.SEGMENT_VAL_CODE and T324628.DELETE_FLG = 'N' and T324628.X_CURRENCY_CODE = 'CAD' and T148543.HIER4_CODE <> '00000000000' and T91397.RECON_TYPE_CODE is not null and T91397.ROW_WID = T324628.GL_ACCOUNT_WID and T91397.ACCOUNT_SEG3_CODE = T148937.SEGMENT_VAL_CODE and T91397.ACCOUNT_SEG3_ATTRIB = T148937.SEGMENT_LOV_ID and T91397.ACCOUNT_SEG2_CODE = T148908.SEGMENT_VAL_CODE and T91397.ACCOUNT_SEG2_ATTRIB = T148908.SEGMENT_LOV_ID and T91397.ACCOUNT_SEG1_CODE = T149255.SEGMENT_VAL_CODE and T91397.ACCOUNT_SEG1_ATTRIB = T149255.SEGMENT_LOV_ID and (T96094.W_STATUS_CODE in ('POSTED', 'REVERSED')) and T91397.GL_ACCOUNT_NUM like '%98%' )
group by T91397.GL_ACCOUNT_NUM, T91707.ACCT_DOC_NUM, T91707.X_LINE_DESCRIPTION, T148543.HIER4_CODE, T148543.HIER4_NAME, T148908.SEGMENT_VAL_DESC, T149255.SEGMENT_VAL_CODE
) D1
) D1
order by c1, c2, c3, c4, c5, c6, c7The plan is,
PLAN_TABLE_OUTPUT
Plan hash value: 3196636288
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Psto
| 0 | SELECT STATEMENT | | 810K| 306M| | 266K (1)| 01:20:03 | | |
| 1 | HASH GROUP BY | | 810K| 306M| 320M| 266K (1)| 01:20:03 | | |
|* 2 | HASH JOIN | | 810K| 306M| 38M| 239K (1)| 01:11:56 | | |
|* 3 | MAT_VIEW ACCESS FULL | WC_GL_OTHER_F_MV | 1137K| 40M| | 9771 (2)| 00:0
|* 4 | HASH JOIN | | 531K| 189M| | 222K (1)| 01:06:38 | | |
| 5 | INLIST ITERATOR | | | | | | | | |
|* 6 | INDEX RANGE SCAN | W_STATUS_D_U2 | 4 | 56 | | 1 (0)| 00:00:01 |
|* 7 | HASH JOIN | | 607K| 208M| 8704K| 222K (1)| 01:06:38 | | |
|* 8 | HASH JOIN | | 40245 | 8214K| 2464K| 10843 (2)| 00:03:16 | | |
| 9 | VIEW | index$_join$_007 | 35148 | 2025K| | 122 (32)| 00:00:03 | |
|* 10 | HASH JOIN | | | | | | | | |
|* 11 | HASH JOIN | | | | | | | | |
|* 12 | HASH JOIN | | | | | | | | |
| 13 | BITMAP CONVERSION TO ROWIDS | | 35148 | 2025K| | 1 (0)| 00:00:01 | |
| 14 | BITMAP INDEX FULL SCAN | W_HIERARCHY_D_M2 | | | | | | |
| 15 | BITMAP CONVERSION TO ROWIDS | | 35148 | 2025K| | 24 (0)| 00:00:01 | |
| 16 | BITMAP INDEX FULL SCAN | W_HIERARCHY_D_M4 | | | | | | |
| 17 | BITMAP CONVERSION TO ROWIDS | | 35148 | 2025K| | 24 (0)| 00:00:01 | |
|* 18 | BITMAP INDEX FULL SCAN | X_W_HIERARCHY_D_M11 | | | | | | |
| 19 | BITMAP CONVERSION TO ROWIDS | | 35148 | 2025K| | 33 (0)| 00:00:01 | |
| 20 | BITMAP INDEX FULL SCAN | X_W_HIERARCHY_D_M12 | | | | | | |
|* 21 | HASH JOIN | | 40246 | 5895K| 4096K| 10430 (2)| 00:03:08 | |
| 22 | VIEW | index$_join$_008 | 65417 | 3321K| | 197 (14)| 00:00:04 |
|* 23 | HASH JOIN | | | | | | | | |
|* 24 | HASH JOIN | | | | | | | | |
| 25 | BITMAP CONVERSION TO ROWIDS | | 65417 | 3321K| | 3 (0)| 00:00:01 | |
| 26 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M1 | | | | | | |
| 27 | BITMAP CONVERSION TO ROWIDS | | 65417 | 3321K| | 66 (2)| 00:00:02 | |
| 28 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M2 | | | | | | |
| 29 | BITMAP CONVERSION TO ROWIDS | | 65417 | 3321K| | 100 (1)| 00:00:02 | |
| 30 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M3 | | | | | | |
|* 31 | HASH JOIN | | 40246 | 3851K| | 9953 (1)| 00:03:00 | | |
| 32 | VIEW | index$_join$_006 | 65417 | 1149K| | 82 (18)| 00:00:02 | |
|* 33 | HASH JOIN | | | | | | | | |
| 34 | BITMAP CONVERSION TO ROWIDS | | 65417 | 1149K| | 3 (0)| 00:00:01 | |
| 35 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M1 | | | | | | |
| 36 | BITMAP CONVERSION TO ROWIDS | | 65417 | 1149K| | 66 (2)| 00:00:02 | |
| 37 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M2 | | | | | | |
|* 38 | HASH JOIN | | 40246 | 3144K| | 9870 (1)| 00:02:58 | | |
| 39 | VIEW | index$_join$_005 | 65417 | 1149K| | 82 (18)| 00:00:02 | |
|* 40 | HASH JOIN | | | | | | | | |
| 41 | BITMAP CONVERSION TO ROWIDS| | 65417 | 1149K| | 3 (0)| 00:00:01 | |
| 42 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M1 | | | | | | |
| 43 | BITMAP CONVERSION TO ROWIDS| | 65417 | 1149K| | 66 (2)| 00:00:02 | |
| 44 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M2 | | | | | | |
|* 45 | TABLE ACCESS FULL | W_GL_ACCOUNT_D | 40246 | 2436K| | 9788 (1)| 00:02:57
| 46 | PARTITION RANGE ALL | | 11M| 4261M| | 152K (2)| 00:45:43 | 1 |1048
| 47 | TABLE ACCESS FULL | W_GL_OTHER_F | 11M| 4261M| | 152K (2)| 00:45:43
Predicate Information (identified by operation id):
2 - access("T96094"."ROW_WID"="T324628"."DOC_STATUS_WID" AND "T91397"."ROW_WID"="T324628"."GL_ACC
3 - filter("T324628"."X_CURRENCY_CODE"='CAD' AND "T324628"."DELETE_FLG"='N')
4 - access("T91707"."DOC_STATUS_WID"="T96094"."ROW_WID")
6 - access("T96094"."W_STATUS_CODE"='POSTED' OR "T96094"."W_STATUS_CODE"='REVERSED')
7 - access("T91397"."ROW_WID"="T91707"."GL_ACCOUNT_WID")
8 - access("T148543"."HIER_CODE"="T148937"."SEGMENT_LOV_ID" AND "T148543"."HIER20_CODE"="T148937"
10 - access(ROWID=ROWID)
11 - access(ROWID=ROWID)
12 - access(ROWID=ROWID)
18 - filter("T148543"."HIER4_CODE"<>'00000000000')
21 - access("T91397"."ACCOUNT_SEG2_CODE"="T148908"."SEGMENT_VAL_CODE" AND
"T91397"."ACCOUNT_SEG2_ATTRIB"="T148908"."SEGMENT_LOV_ID")
23 - access(ROWID=ROWID)
24 - access(ROWID=ROWID)
31 - access("T91397"."ACCOUNT_SEG3_CODE"="T148937"."SEGMENT_VAL_CODE" AND
"T91397"."ACCOUNT_SEG3_ATTRIB"="T148937"."SEGMENT_LOV_ID")
33 - access(ROWID=ROWID)
38 - access("T91397"."ACCOUNT_SEG1_CODE"="T149255"."SEGMENT_VAL_CODE" AND
"T91397"."ACCOUNT_SEG1_ATTRIB"="T149255"."SEGMENT_LOV_ID")
40 - access(ROWID=ROWID)
45 - filter("T91397"."GL_ACCOUNT_NUM" LIKE '%98%' AND "T91397"."RECON_TYPE_CODE" IS NOT NULL)
79 rows selected.user605926 wrote:
We have this query which is taking a long time to execute. From the explain plan what i found out is there is a full table scan going on W_GL_OTHER_F. Please help in identifying the problem area and solutions.
The plan is,
PLAN_TABLE_OUTPUT
Plan hash value: 3196636288
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Psto
| 0 | SELECT STATEMENT | | 810K| 306M| | 266K (1)| 01:20:03 | | |
| 1 | HASH GROUP BY | | 810K| 306M| 320M| 266K (1)| 01:20:03 | | |
|* 2 | HASH JOIN | | 810K| 306M| 38M| 239K (1)| 01:11:56 | | |
|* 3 | MAT_VIEW ACCESS FULL | WC_GL_OTHER_F_MV | 1137K| 40M| | 9771 (2)| 00:0
|* 4 | HASH JOIN | | 531K| 189M| | 222K (1)| 01:06:38 | | |
| 5 | INLIST ITERATOR | | | | | | | | |
|* 6 | INDEX RANGE SCAN | W_STATUS_D_U2 | 4 | 56 | | 1 (0)| 00:00:01 |
|* 7 | HASH JOIN | | 607K| 208M| 8704K| 222K (1)| 01:06:38 | | |
|* 8 | HASH JOIN | | 40245 | 8214K| 2464K| 10843 (2)| 00:03:16 | | |
| 9 | VIEW | index$_join$_007 | 35148 | 2025K| | 122 (32)| 00:00:03 | |
|* 10 | HASH JOIN | | | | | | | | |
|* 11 | HASH JOIN | | | | | | | | |
|* 12 | HASH JOIN | | | | | | | | |
| 13 | BITMAP CONVERSION TO ROWIDS | | 35148 | 2025K| | 1 (0)| 00:00:01 | |
| 14 | BITMAP INDEX FULL SCAN | W_HIERARCHY_D_M2 | | | | | | |
| 15 | BITMAP CONVERSION TO ROWIDS | | 35148 | 2025K| | 24 (0)| 00:00:01 | |
| 16 | BITMAP INDEX FULL SCAN | W_HIERARCHY_D_M4 | | | | | | |
| 17 | BITMAP CONVERSION TO ROWIDS | | 35148 | 2025K| | 24 (0)| 00:00:01 | |
|* 18 | BITMAP INDEX FULL SCAN | X_W_HIERARCHY_D_M11 | | | | | | |
| 19 | BITMAP CONVERSION TO ROWIDS | | 35148 | 2025K| | 33 (0)| 00:00:01 | |
| 20 | BITMAP INDEX FULL SCAN | X_W_HIERARCHY_D_M12 | | | | | | |
|* 21 | HASH JOIN | | 40246 | 5895K| 4096K| 10430 (2)| 00:03:08 | |
| 22 | VIEW | index$_join$_008 | 65417 | 3321K| | 197 (14)| 00:00:04 |
|* 23 | HASH JOIN | | | | | | | | |
|* 24 | HASH JOIN | | | | | | | | |
| 25 | BITMAP CONVERSION TO ROWIDS | | 65417 | 3321K| | 3 (0)| 00:00:01 | |
| 26 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M1 | | | | | | |
| 27 | BITMAP CONVERSION TO ROWIDS | | 65417 | 3321K| | 66 (2)| 00:00:02 | |
| 28 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M2 | | | | | | |
| 29 | BITMAP CONVERSION TO ROWIDS | | 65417 | 3321K| | 100 (1)| 00:00:02 | |
| 30 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M3 | | | | | | |
|* 31 | HASH JOIN | | 40246 | 3851K| | 9953 (1)| 00:03:00 | | |
| 32 | VIEW | index$_join$_006 | 65417 | 1149K| | 82 (18)| 00:00:02 | |
|* 33 | HASH JOIN | | | | | | | | |
| 34 | BITMAP CONVERSION TO ROWIDS | | 65417 | 1149K| | 3 (0)| 00:00:01 | |
| 35 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M1 | | | | | | |
| 36 | BITMAP CONVERSION TO ROWIDS | | 65417 | 1149K| | 66 (2)| 00:00:02 | |
| 37 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M2 | | | | | | |
|* 38 | HASH JOIN | | 40246 | 3144K| | 9870 (1)| 00:02:58 | | |
| 39 | VIEW | index$_join$_005 | 65417 | 1149K| | 82 (18)| 00:00:02 | |
|* 40 | HASH JOIN | | | | | | | | |
| 41 | BITMAP CONVERSION TO ROWIDS| | 65417 | 1149K| | 3 (0)| 00:00:01 | |
| 42 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M1 | | | | | | |
| 43 | BITMAP CONVERSION TO ROWIDS| | 65417 | 1149K| | 66 (2)| 00:00:02 | |
| 44 | BITMAP INDEX FULL SCAN | W_GL_SEGMENT_D_M2 | | | | | | |
|* 45 | TABLE ACCESS FULL | W_GL_ACCOUNT_D | 40246 | 2436K| | 9788 (1)| 00:02:57
| 46 | PARTITION RANGE ALL | | 11M| 4261M| | 152K (2)| 00:45:43 | 1 |1048
| 47 | TABLE ACCESS FULL | W_GL_OTHER_F | 11M| 4261M| | 152K (2)| 00:45:43
Predicate Information (identified by operation id):
2 - access("T96094"."ROW_WID"="T324628"."DOC_STATUS_WID" AND "T91397"."ROW_WID"="T324628"."GL_ACC
3 - filter("T324628"."X_CURRENCY_CODE"='CAD' AND "T324628"."DELETE_FLG"='N')
4 - access("T91707"."DOC_STATUS_WID"="T96094"."ROW_WID")
6 - access("T96094"."W_STATUS_CODE"='POSTED' OR "T96094"."W_STATUS_CODE"='REVERSED')
7 - access("T91397"."ROW_WID"="T91707"."GL_ACCOUNT_WID")
8 - access("T148543"."HIER_CODE"="T148937"."SEGMENT_LOV_ID" AND "T148543"."HIER20_CODE"="T148937"
10 - access(ROWID=ROWID)
11 - access(ROWID=ROWID)
12 - access(ROWID=ROWID)
18 - filter("T148543"."HIER4_CODE"<>'00000000000')
21 - access("T91397"."ACCOUNT_SEG2_CODE"="T148908"."SEGMENT_VAL_CODE" AND
"T91397"."ACCOUNT_SEG2_ATTRIB"="T148908"."SEGMENT_LOV_ID")
23 - access(ROWID=ROWID)
24 - access(ROWID=ROWID)
31 - access("T91397"."ACCOUNT_SEG3_CODE"="T148937"."SEGMENT_VAL_CODE" AND
"T91397"."ACCOUNT_SEG3_ATTRIB"="T148937"."SEGMENT_LOV_ID")
33 - access(ROWID=ROWID)
38 - access("T91397"."ACCOUNT_SEG1_CODE"="T149255"."SEGMENT_VAL_CODE" AND
"T91397"."ACCOUNT_SEG1_ATTRIB"="T149255"."SEGMENT_LOV_ID")
40 - access(ROWID=ROWID)
45 - filter("T91397"."GL_ACCOUNT_NUM" LIKE '%98%' AND "T91397"."RECON_TYPE_CODE" IS NOT NULL)
79 rows selected.
You may want to have a look at <a href="HOW TO: Post a SQL statement tuning request - template posting">HOW TO: Post a SQL statement tuning request - template posting</a> to see what more details are needed in order for somebody to provide better answer.
Based on what you have posted so far, you may want to share details of following questions (in addition to details in above link)
1) How much time does the query currently take to execute? How much time do you expect it to take? Also, how are you measuring query execution time?
2) Your plan suggests that the query is expected to return 810K rows. Is this figure close to actual number of records? What are you doing with this huge amount of data? -
Select query giving Time out dump
Hi All,
I have written a select query on a table in BW system.The code for the same is attached below.The table contains some 6,00,000 records.This query is giving a time out error.Kindly look into the query and advice ways to make it work.Thanks.
IF NOT lt_temp[] IS INITIAL.
SELECT /bic/zprrmatnr objvers /bic/zprclwynr /bic/zprrmdlr
FROM /bic/pzprrmatnr
INTO CORRESPONDING FIELDS OF TABLE lt_zprrmatnr
FOR ALL ENTRIES IN lt_temp
WHERE /bic/zprclwynr = lt_temp-temp
AND objvers = 'A'.
ENDIF.
Thanks and Regards,
FaisalNot only is it BW, it is also a customer table. Have a look here on how to research yourself:
Please Read before Posting in the Performance and Tuning Forum
Thomas -
Select Query on time stamp.
Hello Gurus,
Please help me in writing a select query with the where condition on time stamp for the field IBSP-VALFR and IBSP-VALTO, with the current system time stamp. I need pick all the values which falls in these two fields with the current time stamp.
Thanks & Regards,
Naresh.Hi,
some how my code is not working...Please look at my code.
convert date sy-datum
time sy-uzeit
into time stamp low_validity
time zone sy-zonlo.
SELECT SP_INSTANCE INSTANCE EQUNO MATNO SERNO
FROM IBSP INTO TABLE IT_IBSP
for all entries in it_IBIN
where ( SP_INSTANCE = IT_IBIN-INSTANCE OR
INSTANCE = IT_IBIN-INSTANCE ) and
VALFR Le low_validity and
VALTO ge low_validity.
Its getting the values for which VALTO is less than current date.
Thanks & Regards,
Naresh. -
A simple select query taking forever
Hi All
I am not able to execute a simple select query, I traced my session and here is TKPROF of that Trace.
Solaris 8 , Oracle 10.2.0.4.0
TKPROF: Release 10.2.0.4.0 -
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: 502_ora_28260.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
select OBJECT_ID , ORACLE_USERNAME , SESSION_ID
from
v$locked_object
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.03 32.86 0 0 6 0
total 3 0.03 32.86 0 0 6 0
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: SYS
Rows Row Source Operation
0 MERGE JOIN (cr=0 pr=0 pw=0 time=60 us)
0 SORT JOIN (cr=0 pr=0 pw=0 time=58 us)
0 MERGE JOIN (cr=0 pr=0 pw=0 time=42 us)
1 SORT JOIN (cr=0 pr=0 pw=0 time=2443 us)
1105 FIXED TABLE FULL X$KSUSE (cr=0 pr=0 pw=0 time=1204 us)
0 SORT JOIN (cr=0 pr=0 pw=0 time=41 us)
1001 FIXED TABLE FULL X$KTCXB (cr=0 pr=0 pw=0 time=16132 us)
0 SORT JOIN (cr=0 pr=0 pw=0 time=0 us)
0 FIXED TABLE FULL X$KTADM (cr=0 pr=0 pw=0 time=0 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
buffer busy waits 34 0.97 32.83
SQL*Net break/reset to client 1 0.00 0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.03 32.86 0 0 6 0
total 3 0.03 32.86 0 0 6 0
Misses in library cache during parse: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 1 19.00 19.00
buffer busy waits 34 0.97 32.83
SQL*Net break/reset to client 1 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
1 user SQL statements in session.
0 internal SQL statements in session.
1 SQL statements in session.
Trace file: 502_ora_28260.trc
Trace file compatibility: 10.01.00
Sort options: default
0 session in tracefile.
1 user SQL statements in trace file.
0 internal SQL statements in trace file.
1 SQL statements in trace file.
1 unique SQL statements in trace file.
64 lines in trace file.
32 elapsed seconds in trace file. There is nothing fishy in alert logs... Please guide
ThanksThere it is TOP
$ RUMPSHAKER>top
load averages: 6.63, 7.45, 7.88; up 33+12:02:33
3631 processes: 3616 sleeping, 5 zombie, 1 stopped, 9 on cpu
CPU states: 58.6% idle, 18.2% user, 23.2% kernel, 0.0% iowait, 0.0% swap
Memory: 192G phys mem, 92G free mem, 96G swap, 96G free swap
PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
13752 ora0005 1 19 0 4243M 4219M sleep 5:21 62.78% oracle
17758 ora0005 1 25 0 1174M 1156M cpu 1:05 37.12% oracle
17923 root 1 57 0 18M 14M sleep 689:07 13.59% ecap_monitor
20777 root 12 58 0 14M 13M sleep 864:33 11.55% OracleAgent
18884 ora0004 1 1 0 830M 813M sleep 0:01 9.54% oracle
12070 ora0004 61 58 0 320M 315M sleep 28.5H 8.29% emagent
20347 root 16 59 0 33M 25M sleep 26.0H 6.34% caiUxsA2
17949 ist0005 1 53 0 7984K 4984K cpu 0:00 3.93% top
1 root 1 59 0 2912K 1288K sleep 32.2H 3.75% init
15035 ora0001 1 46 0 32M 22M sleep 166:43 2.98% tnslsnr
5748 ora0004 11 54 0 516M 496M sleep 389:37 2.78% oracle
20567 ora0004 1 55 0 27M 22M sleep 0:00 2.69% sqlplus
6730 ora0001 1 33 0 632M 616M sleep 0:06 2.67% oracle
20557 ora0004 1 56 0 27M 23M sleep 0:00 2.53% sqlplus
5355 ora0005 1 59 0 1154M 1137M sleep 0:04 2.46% oracleand VMSTAT 2 5
$ RUMPSHAKER> vmstat 2 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr s0 s1 s2 sd in sy cs us sy id
6 8 0 143125576 74272080 4628 24012 488 150 149 0 0 4 4 -2 0 25037 192698 65249 38 26 36
1 3 0 162803992 95246464 1989 6989 0 4 4 0 0 6 6 0 0 9170 57822 26434 8 13 79
1 7 0 162801352 95240296 3043 15633 4 9737 9682 0 0 0 0 0 0 11277 73516 38200 16 16 68
3 10 0 162801560 95227920 3326 12729 16 16862 16774 0 0 1 1 0 0 11377 86054 44758 16 17 68
1 10 0 162784520 95186488 9638 48359 24 11682 11626 0 0 13 13 0 0 13484 149366 44205 23 29 47 -
Select query taking long time (more then 6 min)
Dear experts,
DATA:IT_CHEQ2 TYPE TABLE OF TY_BSAS,
WA_CHEQ2 LIKE LINE OF IT_CHEQ2.
DATA : IT_CHEQ3 TYPE STANDARD TABLE OF TY_BSAS WITH HEADER LINE.
TYPES:BEGIN OF TY_BSAS,
BUKRS TYPE BSAS-BUKRS,
HKONT TYPE BSAS-HKONT,
AUGDT TYPE BSAS-AUGDT,
AUGBL TYPE BSAK-AUGBL,
ZUONR TYPE BSAK-ZUONR,
GJAHR TYPE BSAK-GJAHR,
BELNR TYPE BSAK-BELNR,
BUZEI TYPE BSAK-BUZEI,
BUDAT TYPE BSAK-BUDAT,
XBLNR TYPE BSAK-XBLNR,
BLART TYPE BSAK-BLART,
SHKZG TYPE BSAK-SHKZG,
DMBTR TYPE BSAK-DMBTR,
WMWST TYPE BSAK-WMWST,
AUGGJ TYPE BSAK-AUGGJ, " CLEARING FYSICAL YEAR
OT_TAX TYPE BSAK-DMBTR,
TDS TYPE BSAK-DMBTR,
VAT TYPE BSAK-DMBTR, "Vat amount
WCT TYPE BSAK-DMBTR,
ADV TYPE BSAK-DMBTR, "Advance
CHAMT TYPE BSAK-DMBTR,
CHNO TYPE PAYR-CHECT,
CHDATE TYPE PAYR-ZALDT,
DBIT_NOTE TYPE BSAK-DMBTR,
PAY_ADJ TYPE BSAK-DMBTR,
PEND_SES TYPE BSAK-DMBTR, "PENDING SES
CR_PARTY(50) TYPE C,
END OF TY_BSAS.
SELECT BUKRS HKONT AUGDT AUGBL ZUONR GJAHR BELNR BUZEI BUDAT XBLNR BLART SHKZG
DMBTR WMWST
FROM BSAS INTO " APPENDING
CORRESPONDING FIELDS OF TABLE IT_CHEQ3
FOR ALL ENTRIES IN IT_CHEQ2
WHERE AUGBL = IT_CHEQ2-AUGBL and
BUKRS = IT_CHEQ2-BUKRS AND
* AUGBL = IT_CHEQ2-AUGBL
GJAHR = IT_CHEQ2-GJAHR
AND XBLNR = IT_CHEQ2-XBLNR.
line company code hkont augdt augbl zuonr gjahr belnr buzei budat
1 1018 0012100030 20110831 2100009710 20110831 2011 2100009710 005 20110831
xblnr blart shkzg
RA03 KZ H 37067.00 0.00 2011 0.00 0.00
2 1018 0012100030 20110831 2100009710 20110831 2011 2100009710 006 20110831
RA03 KZ H 393850.00 0.00 2011 0.00 0.00
3 1018 0012100030 20110831 2100009710 20110831 2011 2100009710 004 20110831 RA03 KZ S 723589.13 0.00 2011 0.00 0.00
4 1018 0012100030 20110831 2100009710 20110823 2011 3900001250 001 20110823 RA03 RS H 712921.13 0.00 2011 0.00 0.00
5 1018 0023200000 20110831 2100009710 20110831 2011 2100009710 008 20110831 RA03 KZ H 21788.00 0.00 2011 0.00 0.00
6 1018 0023200000 20110831 2100009710 20110831 2011 2100009710 007 20110831 RA03 KZ H 1162821.00 0.00 2011 0.00 0.00
if i put same entry in se11 for bsas it takes 7 second
and in query takes more then 6 min ,kindly tell why
help me gurus
regards
victorTested point 2.
There is no difference.
REPORT Z_YZ_SELECT_ORDER.
types: begin of t_orderadm,
description type CRMT_PROCESS_DESCRIPTION,
created_at type COMT_CREATED_AT_USR,
LOGICAL_SYSTEM type CRMT_LOGSYS,
TEMPLATE_TYPE type CRMT_TEMPLATE_TYPE_DB,
VERIFY_DATE type CRMT_VERIFY_DATE,
GUID type CRMT_OBJECT_GUID,
end of t_orderadm.
types: begin of t_orderadm_1,
GUID type CRMT_OBJECT_GUID,
description type CRMT_PROCESS_DESCRIPTION,
LOGICAL_SYSTEM type CRMT_LOGSYS,
TEMPLATE_TYPE type CRMT_TEMPLATE_TYPE_DB,
created_at type COMT_CREATED_AT_USR,
VERIFY_DATE type CRMT_VERIFY_DATE,
end of t_orderadm_1.
data: lt_orders type table of t_orderadm,
lt_orders_1 type table of t_orderadm_1.
select description created_at logical_system template_type verify_date guid
into table lt_orders
from crmd_orderadm_h.
select guid description logical_system template_type created_at verify_date
into table lt_orders_1
from crmd_orderadm_h.
write 'done'.
First select - mixed order of fields. Response time: 82.155 microseconds for 39380 records selected.
Second select - fields in the order of the table. Response time: 81.061 microseconds for the same 39380 records selected.
Then I changed the order of SELECT statements. I have put first the select with ordered fields, and second - select with mixed order of fields. The runtimes were the following:
Ordered fields - 82.649 microseconds
Mixed order of fields - 80.270 microseconds.
So I'm going to change the Wiki page in order to avoid in future advices that make no sense. -
Hello,
i have created one query based on inventory cube 0IC_C03. when i am executing the infocube based on a particular date i am able to see the output but when i am executing the query on the basis of that particular date given while executing the cube the query is taking long time to execute and throwing a message of time limit exceed.
could anyone suggest me why the query is showing such nessage along with resolution.
Thanks,
Kumkum
Edited by: kumkum basu on Nov 29, 2010 2:33 PMHi,
There can be number of reason.
What you can do is:-
put the unwanted characteristics in Free Characteristics
Remove unwanted cell reference
Try using partitions in cubes
Use aggregates for summarised data.
f the above options doesnt work, then try pre-caching.This will definitely help!
Use proper selections to get small subset of data.
Goto RSRT>> type your query name>> Query properties>> select cache mode=4
In addition to RSRT, ST05 (sql trace), SE30 (runtime analysis) and system statistics (ST03) may help you in identifying performance issues with a report.
Thanks,.
Saveen Kumar -
Simple Select Query Taking 5-10s
We have a web server on the same lan as the DB server.
A simple select * from tablename (~100 entries) is taking
anywhere from 30ms to 10 seconds lan. ASP code on the web server
provides instant (30ms) queries. Ping is never <1ms. If I point
to a remote DB server, the same query is never more than 300ms
(which is great for over the internet).
I enabled logging in CFAdmin -> Datasources and shortly
after my select * from tablename I see this:
spy(2009/02/28 16:39:00.539)>>
Connection[2].setReadOnly(boolean readOnly)
spy(2009/02/28 16:39:00.539)>> readOnly = false
spy(2009/02/28 16:39:00.539)>> OK
spy(2009/02/28 16:39:05.726)>> OK (true)
We need to get this up and running ASAP. Please help!!> I'm connecting to SQL Server 2000 on a Win2k3 box.
> The default CF8 Installation.
> Every table this happens for.
OK. I think CF8 runs the most recent JDBC drivers too. It
might pay to
check that though.
> Select * is needed, because we have existing sites we
are migrating a lot of
> which use select *.
Sure. But just for the purposes of experimentation, change
your test code
to specify columns to see if it makes any difference.
It might pay to get hold of FusionReactor to check what CF is
doing with
the queries, under the hood.
Adam -
I have a query -->select c1,c2,c3 from table1 . This query takes only few milliseconds. But when I take count from the same query i.e. when I execute select count(c1,c2,c3) from table1 then it takes a very long time (about 1 min). The table1 contains about 25000 rows. Please help to improve performance of Count query.
Satej wrote:
I have a query -->select c1,c2,c3 from table1 . This query takes only few milliseconds. But when I take count from the same query i.e. when I execute select count(c1,c2,c3) from table1 then it takes a very long time (about 1 min).Classic misperception of Toad, SQL Navigator and similar tool users. All these tools fetch just first result screen and show time it took to fetch just that and not the time to fetch all rows. And in order to count you need to fetch all rows.l That is why select count(*) takes longer. But 1 min for 25000 rows is a bit long. Check execution plan to see what is going on.
SY. -
Hi:
We are using a common component for generating query screens wherein we just have to pass a query number to the component which in turn return a list view of records.
We have a particular Query which when executed through Toad or any SQL tool returns records within 4-5 seconds but the same one takes almost 3 minutes to load from Front End.
What could be the possible reason for the page to take so much time to load.
We are using WebSphere 6.0.2.17 server. Is there any settings to be done for statement cache size or for any connection timeout or is there anything to be done at Oracle side.
Since the moment we change the query number to some simple query like select * from dual kind the screen loads instantly.
P.S: The query takes almost 4-5 seconds to execute in backend through TOAD.
Avadhoot SawantSo 45 or 47? Nevertheless ...
This is hardly a heavy calculation, the savings will be dismal. Also anything numeric is very easy on CPU in general.
But
convert( numeric(8,5), (convert( numeric,T3.COl7) / 1000000))
is not optimal.
CONVERT( NUMERIC(8,5),300 / 1000000.00000 )
Is
Now it boils to how to make load faster: do it in parallel. Find how many sockets the machine have and split the table into as many chunks. Also profile to find out where it spends most of the time. I saw sometimes the network is not letting me thru so you
may want to play with buffers, and packet sizes, for example if OLEDB used increase the packet size two times see if works faster, then x2 more and so forth.
To help you further you need to tell more e.g. what is this source, destination, how you configured the load.
Please understand that there is no Silver Bullet anywhere, or a blanket solution, and you need to tell me your desired load time. E.g. if you tell me it needs to load in 5 min I will give your ask a pass.
Arthur
MyBlog
Twitter
Maybe you are looking for
-
Will my old monitors are compatible with the new Mac Pro?
I'm thinking about buy a new workstations (MacPro) but I need to know if my Monitors are compatible or I need to buy a new ones. I have a Cin Dsplay 23-inch DVI Early 2007 and a LED Cinema Display (24-inch). Kind regards
-
Risk Analysis Button Grayed Out
Hello All, we upgraded to SP15 on GRC10.0 and Run Risk Analysis button is grayed out while trying to look at risk violations for chnage request approval. Any ideas? It was working previously.
-
Photoshop like app for new iPad...
I'm needing a bit of help here from all you guru's of the iPad world..I'm a iPad newby crossover from the Xoom crowd and am looking for the best iPad app that will let me do the same basic functions that my Photoshop CS5 I use on my PC does...import
-
Why is Nathan Volker in my "People I Follow" list...
when I didn't add him and why doesn't pressing the "Stop Following" button get rid of him?
-
Is there style-match option in photoshop elements 10 & 11?
if it wasent.... where can i download elements 9?