High Logical reads/gets per exec
Hi,
Oracle version - 11.2.0.2
I am facing high gets/exec for queries.The queries are fine tuned with proper index usage.I checked with SQL tuning set also which says 'no recommendation for this query'.
We have sufficient SGA and shared pool size.Gets/per exec are in 9000 range.
Also I am seeing latch:cache buffer chains in top events which is happening for a delete query.Will altering freelist for this table help?
Kindly assist me with this.
Thanks.
Hi,
A bit late but PFB the trace file contents.
TKPROF: Release 11.2.0.2.0 - Development on Thu Oct 24 21:39:25 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: PADB_ora_65339438_NISTRY1.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
The following statement encountered a error during parse:
BEGIN :B1 := 'DOP';SQL>; END;
WAIT #45735296
Error encountered: ORA-06550
SQL ID: bt3nb4jyxdhnk Plan Hash: 0
BEGIN dbms_monitor.session_trace_enable(waits=>true, binds=>true); END;
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93
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
SQL*Net message from client 1 13.03 13.03
SQL ID: bdbaumr2rur17 Plan Hash: 0
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12'
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 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Parsing user id: 93
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
SQL*Net message from client 1 30.60 30.60
SQL ID: 715kzr79k99cw Plan Hash: 0
BEGIN :B2:=400013; END;
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 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93
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 2 11.56 18.88
SQL*Net break/reset to client 1 0.00 0.00
SQL ID: 7usux68w7hu01 Plan Hash: 0
BEGIN :B1 := 'DOP'; END;
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 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93
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
SQL*Net message from client 1 15.50 15.50
SQL ID: 3hvm4jjpfx0zb Plan Hash: 1496842891
SELECT ADD_LINE1, ADD_LINE2, ADD_LINE3, DOMICILE, CITY, ZIP, ORGKEY
FROM
ADD WHERE ADD.ACTID = :B2 AND ADD.ADDCATEGORY =
'Mail' AND ADD.START_DATE<SYSDATE AND ADD.END_DATE>SYSDATE AND
BANK_ID = :B1
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 2 0.00 0.00 1 6 0 1
total 4 0.00 0.01 1 6 0 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 TABLE ACCESS BY INDEX ROWID ADD (cr=6 pr=1 pw=0 time=4193 us cost=1 size=163 card=1)
2 2 2 INDEX RANGE SCAN IX_ADD_ACCID_NEW (cr=4 pr=0 pw=0 time=28 us cost=1 size=0 card=2)(object id 79696)
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
Disk file operations I/O 1 0.00 0.00
db file sequential read 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
SQL ID: 96g93hntrzjtr Plan Hash: 841937906
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#,
sample_size, minimum, maximum, distcnt, lowval, hival, density, col#,
spare1, spare2, avgcln
from
hist_head$ where obj#=:1 and intcol#=:2
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 19 0.00 0.00 0 0 0 0
Fetch 19 0.00 0.01 2 76 0 19
total 39 0.00 0.01 2 76 0 19
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=4 pr=0 pw=0 time=42 us)
1 1 1 INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=3 pr=0 pw=0 time=32 us)(object id 427)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 2 0.00 0.01
SQL ID: db78fxqxwxt7r Plan Hash: 2324581405
select /*+ rule */ bucket, endpoint, col#, epvalue
from
histgrm$ where obj#=:1 and intcol#=:2 and row#=:3 order by bucket
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 5 0.00 0.00 0 0 0 0
Fetch 5 0.01 0.01 4 15 0 53
total 11 0.01 0.01 4 15 0 53
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
3 3 3 SORT ORDER BY (cr=3 pr=2 pw=0 time=8455 us cost=0 size=0 card=0)
3 3 3 TABLE ACCESS CLUSTER HISTGRM$ (cr=3 pr=2 pw=0 time=8428 us)
1 1 1 INDEX UNIQUE SCAN I_OBJ#_INTCOL# (cr=2 pr=1 pw=0 time=4210 us)(object id 422)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 4 0.00 0.01
Disk file operations I/O 1 0.00 0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 4 0.00 0.00 0 0 0 0
Execute 5 0.00 0.00 0 0 0 3
Fetch 2 0.00 0.00 1 6 0 1
total 11 0.00 0.01 1 6 0 4
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 7 0.00 0.00
SQL*Net message from client 6 30.60 78.03
SQL*Net break/reset to client 1 0.00 0.00
db file sequential read 1 0.00 0.00
Disk file operations I/O 1 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 24 0.00 0.00 0 0 0 0
Fetch 24 0.01 0.02 6 91 0 72
total 50 0.01 0.03 6 91 0 72
Misses in library cache during parse: 2
Misses in library cache during execute: 2
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 6 0.00 0.02
Disk file operations I/O 1 0.00 0.00
5 user SQL statements in session.
2 internal SQL statements in session.
7 SQL statements in session.
Trace file: PADB_ora_65339438_NISTRY1.trc
Trace file compatibility: 11.1.0.7
Sort options: default
1 session in tracefile.
5 user SQL statements in trace file.
2 internal SQL statements in trace file.
7 SQL statements in trace file.
7 unique SQL statements in trace file.
495 lines in trace file.
78 elapsed seconds in trace file.
Thanks,
Nisha
Similar Messages
-
Logical Reads are very high when run as sproc and very less logical reads when run as a script
Hello
Have a question,
when i execute a sproc. i get a very high logical reads count and when i run the same sproc converted into script it has very low logical reads what does it mean..I would like you to check query plan during ad-hoc run versus stored procedure execution. As other pointed out it could be due to parameter sniffing.
Balmukund Lakhani
Please mark solved if I've answered your question, vote for it as helpful to help other users find a solution quicker
This posting is provided "AS IS" with no warranties, and confers no rights.
My Blog |
Team Blog | @Twitter
| Facebook
Author: SQL Server 2012 AlwaysOn -
Paperback, Kindle -
I have two databases - one is a clone of the other, amde a few months ago. Database A has somewhat more data, since it's the active production database, but not significantly more - perhaps 10% greater. They are on different boxes. Database A is on a Sun 280R 2-processor box. Database B is on a Dell 2950 with 2 dual-core processors. So this isn't exactly comparing apples to apples. However, when I run the same query on the two databases, I get radically different results. Against Database A, the query takes about 7 minutes. On Database B, it takes about 2 seconds. Logical reads per second on Database A reach 80,000-90,000; on Database B, they're about 3,000. There are a few configuration differences (both databases use automatic memory management):
Database A Database B
db_file_multiblock_read_count 64 16
log_buffer 14290432 2104832
open_cursors 1250 300
sga_max_size 4194304000 536870912
sga_target 2634022912 536870912
shared_pool_reserved_size 38587596 7340032
The timings were taken off-hours so neither database would be busy. I'm baffled by the extreme difference in execution times. Any help appreciated!
Thanks,
Harry
Edited by: harryb on Apr 8, 2009 7:26 PMOK, let's start here....
Database A (TEMPOP)
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.3
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 64
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
===================================================
Database B (TEMPO11)
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.1
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 16
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
=================================================================
Now for the query that's causing the problem:
SELECT dsk_document_attribute.value_text inspect_permit_no,
NVL (activity_task_list.revised_due_date,
activity_task_list.default_due_date
inspect_report_due_date,
agency_interest.master_ai_id agency_interest_id,
agency_interest.master_ai_name agency_interest_name,
get_county_code_single (agency_interest.master_ai_id)
parish_or_county_code,
agency_interest_address.physical_address_line_1 inspect_addr_1,
agency_interest_address.physical_address_line_2 inspect_addr_2,
agency_interest_address.physical_address_line_3 inspect_addr_3,
agency_interest_address.physical_address_municipality inspect_city,
agency_interest_address.physical_address_state_code state_id,
agency_interest_address.physical_address_zip inspect_zip,
person.master_person_first_name person_first_name,
person.master_person_middle_initial person_middle_initial,
person.master_person_last_name person__last_name,
SUBSTR (person_telecom.address_or_phone, 1, 14) person_phone,
activity_task_list.requirement_id
FROM dsk_document_attribute,
agency_interest,
activity_task_list,
agency_interest_address,
dsk_central_file dsk_aaa,
dsk_central_file dsk_frm,
person,
person_telecom
WHERE agency_interest.int_doc_id = 0
AND agency_interest.master_ai_id =
agency_interest_address.master_ai_id
AND agency_interest.int_doc_id = agency_interest_address.int_doc_id
AND agency_interest.master_ai_id = dsk_frm.master_ai_id
AND dsk_aaa.int_doc_id = activity_task_list.int_doc_id
AND dsk_frm.int_doc_id = dsk_document_attribute.int_doc_id
AND dsk_frm.doc_type_specific_code =
dsk_document_attribute.doc_type_specific_code
AND dsk_frm.activity_category_code = 'PER'
AND dsk_frm.activity_class_code = 'GNP'
AND dsk_frm.activity_type_code IN ('MAB', 'NAB', 'REB')
AND dsk_frm.program_code = '80'
AND dsk_frm.doc_type_general_code = 'FRM'
AND dsk_frm.doc_type_specific_code = 'PERSET'
AND dsk_aaa.doc_template_id = 2000
AND dsk_frm.master_ai_id = dsk_aaa.master_ai_id
AND dsk_frm.activity_category_code = dsk_aaa.activity_category_code
AND dsk_frm.program_code = dsk_aaa.program_code
AND dsk_frm.activity_class_code = dsk_aaa.activity_class_code
AND dsk_frm.activity_type_code = dsk_aaa.activity_type_code
AND dsk_frm.activity_year = dsk_aaa.activity_year
AND dsk_frm.activity_num = dsk_aaa.activity_num
AND dsk_document_attribute.doc_attribute_code = 'PERMIT_NO'
AND activity_task_list.requirement_id IN ('3406', '3548', '3474')
AND activity_task_list.reference_task_id = 0
AND NVL (activity_task_list.status_code, '$$$') <> '% '
AND person.master_person_id(+) =
f_get_gp_contact (agency_interest.master_ai_id)
AND person.int_doc_id(+) = 0
AND person.master_person_id = person_telecom.master_person_id(+)
AND person.int_doc_id = person_telecom.int_doc_id(+)
AND person_telecom.telecom_type_code(+) = 'wp';Here's the explain plan for Database A, where the query takes 7-8 minutes or more:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 253 | 34 (3)|
| 1 | NESTED LOOPS | | 1 | 253 | 34 (3)|
| 2 | NESTED LOOPS | | 1 | 224 | 32 (0)|
| 3 | NESTED LOOPS OUTER | | 1 | 169 | 31 (0)|
| 4 | NESTED LOOPS OUTER | | 1 | 144 | 29 (0)|
| 5 | NESTED LOOPS | | 1 | 122 | 27 (0)|
| 6 | NESTED LOOPS | | 1 | 81 | 26 (0)|
PLAN_TABLE_OUTPUT
| 7 | NESTED LOOPS | | 1 | 48 | 19 (0)|
| 8 | INLIST ITERATOR | | | | |
|* 9 | TABLE ACCESS BY INDEX ROWID| ACTIVITY_TASK_LIST | 1 | 21 | 17 (0)|
|* 10 | INDEX RANGE SCAN | ACTIVITY_TASK_LIST_FK11 | 106 | | 4 (0)|
|* 11 | TABLE ACCESS BY INDEX ROWID | DSK_CENTRAL_FILE | 1 | 27 | 2 (0)|
|* 12 | INDEX UNIQUE SCAN | PK_DSK_CENTRAL_FILE | 1 | | 1 (0)|
|* 13 | TABLE ACCESS BY INDEX ROWID | DSK_CENTRAL_FILE | 1 | 33 | 7 (0)|
|* 14 | INDEX RANGE SCAN | CF_MASTER_AI_ID_IND | 9 | | 2 (0)|
| 15 | TABLE ACCESS BY INDEX ROWID | AGENCY_INTEREST | 1 | 41 | 1 (0)|
|* 16 | INDEX UNIQUE SCAN | PK_AGENCY_INTEREST | 1 | | 0 (0)|
| 17 | TABLE ACCESS BY INDEX ROWID | PERSON | 1 | 22 | 2 (0)|
PLAN_TABLE_OUTPUT
|* 18 | INDEX UNIQUE SCAN | PK_PERSON | 1 | | 1 (0)|
| 19 | TABLE ACCESS BY INDEX ROWID | PERSON_TELECOM | 1 | 25 | 2 (0)|
|* 20 | INDEX UNIQUE SCAN | PK_PERSON_TELECOM | 1 | | 1 (0)|
| 21 | TABLE ACCESS BY INDEX ROWID | AGENCY_INTEREST_ADDRESS | 1 | 55 | 1 (0)|
|* 22 | INDEX UNIQUE SCAN | PK_AGENCY_INTEREST_ADDRESS | 1 | | 0 (0)|
| 23 | TABLE ACCESS BY INDEX ROWID | DSK_DOCUMENT_ATTRIBUTE | 1 | 29 | 1 (0)|
|* 24 | INDEX UNIQUE SCAN | PK_DSK_DOCUMENT_ATTRIBUTE | 1 | | 0 (0)|
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
9 - filter("ACTIVITY_TASK_LIST"."REFERENCE_TASK_ID"=0 AND
NVL("ACTIVITY_TASK_LIST"."STATUS_CODE",'$$$')<>'% ')
10 - access("ACTIVITY_TASK_LIST"."REQUIREMENT_ID"=3406 OR
"ACTIVITY_TASK_LIST"."REQUIREMENT_ID"=3474 OR "ACTIVITY_TASK_LIST"."REQUIREMENT_ID"=3548)
11 - filter("DSK_AAA"."DOC_TEMPLATE_ID"=2000 AND "DSK_AAA"."ACTIVITY_CLASS_CODE"='GNP' AND
"DSK_AAA"."PROGRAM_CODE"='80' AND "DSK_AAA"."ACTIVITY_CATEGORY_CODE"='PER' AND
("DSK_AAA"."ACTIVITY_TYPE_CODE"='MAB' OR "DSK_AAA"."ACTIVITY_TYPE_CODE"='NAB' OR
"DSK_AAA"."ACTIVITY_TYPE_CODE"='REB'))
12 - access("ACTIVITY_TASK_LIST"."INT_DOC_ID"="DSK_AAA"."INT_DOC_ID")
13 - filter("DSK_FRM"."ACTIVITY_CLASS_CODE"='GNP' AND "DSK_FRM"."PROGRAM_CODE"='80' AND
PLAN_TABLE_OUTPUT
"DSK_FRM"."DOC_TYPE_SPECIFIC_CODE"='PERSET' AND "DSK_FRM"."ACTIVITY_CATEGORY_CODE"='PER' AND
"DSK_FRM"."DOC_TYPE_GENERAL_CODE"='FRM' AND ("DSK_FRM"."ACTIVITY_TYPE_CODE"='MAB' OR
"DSK_FRM"."ACTIVITY_TYPE_CODE"='NAB' OR "DSK_FRM"."ACTIVITY_TYPE_CODE"='REB') AND
"DSK_FRM"."ACTIVITY_TYPE_CODE"="DSK_AAA"."ACTIVITY_TYPE_CODE" AND
"DSK_FRM"."ACTIVITY_YEAR"="DSK_AAA"."ACTIVITY_YEAR" AND
"DSK_FRM"."ACTIVITY_NUM"="DSK_AAA"."ACTIVITY_NUM")
14 - access("DSK_FRM"."MASTER_AI_ID"="DSK_AAA"."MASTER_AI_ID")
16 - access("AGENCY_INTEREST"."MASTER_AI_ID"="DSK_FRM"."MASTER_AI_ID" AND
"AGENCY_INTEREST"."INT_DOC_ID"=0)
18 - access("PERSON"."MASTER_PERSON_ID"(+)="F_GET_GP_CONTACT"("AGENCY_INTEREST"."MASTER_AI_ID
") AND "PERSON"."INT_DOC_ID"(+)=0)
PLAN_TABLE_OUTPUT
20 - access("PERSON"."MASTER_PERSON_ID"="PERSON_TELECOM"."MASTER_PERSON_ID"(+) AND
"PERSON_TELECOM"."TELECOM_TYPE_CODE"(+)='wp' AND
"PERSON"."INT_DOC_ID"="PERSON_TELECOM"."INT_DOC_ID"(+))
22 - access("AGENCY_INTEREST"."MASTER_AI_ID"="AGENCY_INTEREST_ADDRESS"."MASTER_AI_ID" AND
"AGENCY_INTEREST_ADDRESS"."INT_DOC_ID"=0)
24 - access("DSK_FRM"."INT_DOC_ID"="DSK_DOCUMENT_ATTRIBUTE"."INT_DOC_ID" AND
"DSK_DOCUMENT_ATTRIBUTE"."DOC_ATTRIBUTE_CODE"='PERMIT_NO' AND
"DSK_DOCUMENT_ATTRIBUTE"."DOC_TYPE_SPECIFIC_CODE"='PERSET')============================================================================
Here's the explan plan output for Database B, where the query takes 2-3 seconds:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 289 | 39 (0)|
| 1 | NESTED LOOPS OUTER | | 1 | 289 | 39 (0)|
| 2 | NESTED LOOPS | | 1 | 260 | 37 (0)|
| 3 | NESTED LOOPS | | 1 | 205 | 36 (0)|
| 4 | NESTED LOOPS OUTER | | 1 | 172 | 35 (0)|
| 5 | NESTED LOOPS | | 1 | 145 | 34 (0)|
| 6 | NESTED LOOPS | | 1 | 104 | 33 (0)|
PLAN_TABLE_OUTPUT
| 7 | NESTED LOOPS | | 1 | 61 | 26 (0)|
| 8 | INLIST ITERATOR | | | | |
|* 9 | TABLE ACCESS BY INDEX ROWID| ACTIVITY_TASK_LIST | 1 | 25 | 24 (0)|
|* 10 | INDEX RANGE SCAN | ACTIVITY_TASK_LIST_FK11 | 145 | | 4 (0)|
|* 11 | TABLE ACCESS BY INDEX ROWID | DSK_CENTRAL_FILE | 1 | 36 | 2 (0)|
|* 12 | INDEX UNIQUE SCAN | PK_DSK_CENTRAL_FILE | 1 | | 1 (0)|
|* 13 | TABLE ACCESS BY INDEX ROWID | DSK_CENTRAL_FILE | 1 | 43 | 7 (0)|
|* 14 | INDEX RANGE SCAN | CF_MASTER_AI_ID_IND | 9 | | 2 (0)|
| 15 | TABLE ACCESS BY INDEX ROWID | AGENCY_INTEREST | 1 | 41 | 1 (0)|
|* 16 | INDEX UNIQUE SCAN | PK_AGENCY_INTEREST | 1 | | 0 (0)|
| 17 | TABLE ACCESS BY INDEX ROWID | PERSON | 8 | 216 | 1 (0)|
PLAN_TABLE_OUTPUT
|* 18 | INDEX UNIQUE SCAN | PK_PERSON | 1 | | 0 (0)|
| 19 | TABLE ACCESS BY INDEX ROWID | DSK_DOCUMENT_ATTRIBUTE | 1 | 33 | 1 (0)|
|* 20 | INDEX UNIQUE SCAN | PK_DSK_DOCUMENT_ATTRIBUTE | 1 | | 0 (0)|
| 21 | TABLE ACCESS BY INDEX ROWID | AGENCY_INTEREST_ADDRESS | 1 | 55 | 1 (0)|
|* 22 | INDEX UNIQUE SCAN | PK_AGENCY_INTEREST_ADDRESS | 1 | | 0 (0)|
| 23 | TABLE ACCESS BY INDEX ROWID | PERSON_TELECOM | 1 | 29 | 2 (0)|
|* 24 | INDEX UNIQUE SCAN | PK_PERSON_TELECOM | 1 | | 1 (0)|
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
9 - filter("ACTIVITY_TASK_LIST"."REFERENCE_TASK_ID"=0 AND
NVL("ACTIVITY_TASK_LIST"."STATUS_CODE",'$$$')<>'% ')
10 - access("ACTIVITY_TASK_LIST"."REQUIREMENT_ID"=3406 OR
"ACTIVITY_TASK_LIST"."REQUIREMENT_ID"=3474 OR "ACTIVITY_TASK_LIST"."REQUIREMENT_ID"=3548)
11 - filter("DSK_AAA"."DOC_TEMPLATE_ID"=2000 AND "DSK_AAA"."ACTIVITY_CLASS_CODE"='GNP' AND
"DSK_AAA"."PROGRAM_CODE"='80' AND "DSK_AAA"."ACTIVITY_CATEGORY_CODE"='PER' AND
("DSK_AAA"."ACTIVITY_TYPE_CODE"='MAB' OR "DSK_AAA"."ACTIVITY_TYPE_CODE"='NAB' OR
"DSK_AAA"."ACTIVITY_TYPE_CODE"='REB'))
12 - access("ACTIVITY_TASK_LIST"."INT_DOC_ID"="DSK_AAA"."INT_DOC_ID")
13 - filter("DSK_FRM"."DOC_TYPE_SPECIFIC_CODE"='PERSET' AND
PLAN_TABLE_OUTPUT
"DSK_FRM"."ACTIVITY_CLASS_CODE"='GNP' AND "DSK_FRM"."PROGRAM_CODE"='80' AND
"DSK_FRM"."DOC_TYPE_GENERAL_CODE"='FRM' AND "DSK_FRM"."ACTIVITY_CATEGORY_CODE"='PER' AND
("DSK_FRM"."ACTIVITY_TYPE_CODE"='MAB' OR "DSK_FRM"."ACTIVITY_TYPE_CODE"='NAB' OR
"DSK_FRM"."ACTIVITY_TYPE_CODE"='REB') AND "DSK_FRM"."ACTIVITY_TYPE_CODE"="DSK_AAA"."ACTIVITY_TY
PE_CODE" AND "DSK_FRM"."ACTIVITY_YEAR"="DSK_AAA"."ACTIVITY_YEAR" AND
"DSK_FRM"."ACTIVITY_NUM"="DSK_AAA"."ACTIVITY_NUM")
14 - access("DSK_FRM"."MASTER_AI_ID"="DSK_AAA"."MASTER_AI_ID")
16 - access("AGENCY_INTEREST"."MASTER_AI_ID"="DSK_FRM"."MASTER_AI_ID" AND
"AGENCY_INTEREST"."INT_DOC_ID"=0)
18 - access("PERSON"."MASTER_PERSON_ID"(+)="F_GET_GP_CONTACT"("AGENCY_INTEREST"."MASTER_AI_ID
") AND "PERSON"."INT_DOC_ID"(+)=0)
PLAN_TABLE_OUTPUT
20 - access("DSK_FRM"."INT_DOC_ID"="DSK_DOCUMENT_ATTRIBUTE"."INT_DOC_ID" AND
"DSK_DOCUMENT_ATTRIBUTE"."DOC_ATTRIBUTE_CODE"='PERMIT_NO' AND
"DSK_DOCUMENT_ATTRIBUTE"."DOC_TYPE_SPECIFIC_CODE"='PERSET')
22 - access("AGENCY_INTEREST"."MASTER_AI_ID"="AGENCY_INTEREST_ADDRESS"."MASTER_AI_ID" AND
"AGENCY_INTEREST_ADDRESS"."INT_DOC_ID"=0)
24 - access("PERSON"."MASTER_PERSON_ID"="PERSON_TELECOM"."MASTER_PERSON_ID"(+) AND
"PERSON_TELECOM"."TELECOM_TYPE_CODE"(+)='wp' AND
"PERSON"."INT_DOC_ID"="PERSON_TELECOM"."INT_DOC_ID"(+))===============================================================================
Edited by: harryb on Apr 9, 2009 3:29 PM -
SQL execution does not change, but consistent read get higher
Hi,
Our SQL query execution does not change, but consistent reads get higher in our test enviroment but query looks fine in our development and production environments.
In the Development instance the trace is:
STAT #18446744071526492680 id=1 cnt=1 pid=0 pos=1 obj=7151 op='TABLE ACCESS BY INDEX ROWID MEMBER_CMS_SITE_ACCESS (cr=4 pr=0 pw=0 time=153 us cost=3 size=68 card=1)'
STAT #18446744071526492680 id=2 cnt=1 pid=1 pos=1 obj=7152 op='INDEX UNIQUE SCAN MEMBER_SITE__MEMBERID_SITEID (cr=3 pr=0 pw=0 time=104 us cost=2 size=0 card=1)'
So - we read 3 blocks from the index and then 1 from the table ( to make 4)
In the Test instance the trace is:
STAT #18446744071411593144 id=1 cnt=1 pid=0 pos=1 obj=7151 op='TABLE ACCESS BY INDEX ROWID MEMBER_CMS_SITE_ACCESS (cr=112 pr=0 pw=0 time=2820 us cost=3 size=70 card=1)'
STAT #18446744071411593144 id=2 cnt=1 pid=1 pos=1 obj=7152 op='INDEX UNIQUE SCAN MEMBER_SITE__MEMBERID_SITEID (cr=3 pr=0 pw=0 time=90 us cost=2 size=0 card=1)'
We read 3 blocks from the index but the table needs 109 more which cannot possibly be right.
It looks like we are applying UNDO and those 109 are the work needed to do so.
I have tried flushing the shared pool, and killing some sessions that could possibly be the cause... but with nothing in V$TRANSACTION
I could understand this if there was a long-running transaction that's created a lot of dirty blocks, but there are no transactions at all... so it's not that.
ThanksThe SQL is very simple with only one predication in the where cluse and that is indexed,just like
"select * from table where a=:b0"
Column a is indexed. But ORACLE choose FTS not INDEX SCAN because of out-of-date stats maybe.
So I updated the stats expecting to see ORACLE will choose INDEX SCAN. The fact is that ORACLE will not change existing FTS to INDEX until I flush the entire share pool.That's the problem. -
Hello !
Does the counter of event buffer gets include the logical reads ?
Does the mertic buffer gets include the event of reading from undo buffer ?
Thanks and regards,
Pavel
Edited by: Pavel on Jun 27, 2012 3:08 AM
Edited by: Pavel on Jun 27, 2012 3:35 AM
Edited by: Pavel on Jun 27, 2012 4:13 AMHi,
buffer gets = number of times a block was requested from buffer cache. A buffer get always request in a logical read. Depending on whether or not a copy of the block is available in the buffer cache, a logical read may or may not involve a physical read. So "buffer gets" and "logical reads" are basically synonyms and are often used interchangeably.
Oracle doesn't have a special "undo buffer". Undo blocks are stored in rollback segments in UNDO tablespace, and are managed in the same way data blocks are (they're even protected by redo). If a consistent get requires reading from UNDO tablespace, then statistics counters will show that, i.e. there will be one more consistent get in your autotrace.
For more information and some examples, see a thread at askTom:
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:549546900346542976
Best regards,
Nikolay -
Hello,
The system we use is a kind of OLTP thing.
platform - linux
version - 10.2
here, in the statspack everything seems okay to me except the logical reads.(if not tell)
the problems is, the cpu grows gradually and reaches 100.
i need the cpu to be steady.
can somebody tell what is happening here?
STATSPACK report for
Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
2386172435 apple22a 1 11-Aug-09 23:14 10.2.0.1.0 NO
Host Name: xxxxxxxxx Num CPUs: 4 Phys Memory (MB): 2
~~~~
Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- -------------------
Begin Snap: 1747 11-Aug-09 23:23:46 96 7.6
End Snap: 1752 11-Aug-09 23:34:00 218 12.5
Elapsed: 10.23 (mins)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 2,864M Std Block Size: 8K
Shared Pool Size: 656M Log Buffer: 29,855K
Load Profile Per Second Per Transaction
~~~~~~~~~~~~ --------------- ---------------
Redo size: 8,051,891.15 5,042.02
Logical reads: 289,821.64 181.48
Block changes: 49,889.55 31.24
Physical reads: 197.76 0.12
Physical writes: 717.84 0.45
User calls: 1,908.82 1.20
Parses: 962.84 0.60
Hard parses: 0.25 0.00
Sorts: 591.85 0.37
Logons: 0.35 0.00
Executes: 25,757.48 16.13
Transactions: 1,596.96
% Blocks changed per Read: 17.21 Recursive Call %: 94.11
Rollback per transaction %: 26.58 Rows per Sort: 628.58
Instance Efficiency Percentages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.97 Redo NoWait %: 100.00
Buffer Hit %: 99.93 In-memory Sort %: 100.00
Library Hit %: 100.01 Soft Parse %: 99.97
Execute to Parse %: 96.26 Latch Hit %: 99.78
Parse CPU to Parse Elapsd %: 91.30 % Non-Parse CPU: 99.31
Shared Pool Statistics Begin End
Memory Usage %: 47.56 49.99
% SQL with executions>1: 60.62 73.55
% Memory for SQL w/exec>1: 77.58 84.79
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time
CPU time 1,362 31.6
log file sync 16,960 1,264 75 29.4
PL/SQL lock timer 10 586 58606 13.6
buffer busy waits 57,444 388 7 9.0
enq: TX - row lock contention 12,036 298 25 6.9
Host CPU (CPUs: 4)
~~~~~~~~ Load Average
Begin End User System Idle WIO WCPU
0.20 10.74 53.82 9.51 36.67
Note: There is a 8% discrepancy between the OS Stat total CPU time and
the total CPU time estimated by Statspack
OS Stat CPU time: 2261(s) (BUSY_TIME + IDLE_TIME)
Statspack CPU time: 2456(s) (Elapsed time * num CPUs in end snap)
Instance CPU
~~~~~~~~~~~~
% of total CPU for Instance: 63.51
% of busy CPU for Instance: 100.30
%DB time waiting for CPU - Resource Mgr:
Memory Statistics Begin End
~~~~~~~~~~~~~~~~~ ------------ ------------
Host Mem (MB): 1.9 .0
SGA use (MB): 3,584.0 3,584.0
PGA use (MB): 164.2 258.5
% Host Mem used for SGA+PGA: 194875.2 8987233.1
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
log file sync 16,960 4 1,264 75 0.0
PL/SQL lock timer 10 100 586 58606 0.0
buffer busy waits 57,444 0 388 7 0.1
enq: TX - row lock contention 12,036 0 298 25 0.0
log file parallel write 11,870 0 163 14 0.0
db file sequential read 21,324 0 95 4 0.0
log file sequential read 3,963 0 47 12 0.0
db file scattered read 22,614 0 29 1 0.0
log file switch completion 102 17 28 272 0.0
latch: cache buffers chains 5,829 0 11 2 0.0
Log archive I/O 4,346 0 9 2 0.0
enq: TX - index contention 1,153 0 7 6 0.0
latch free 1,483 0 4 3 0.0
control file parallel write 328 0 4 11 0.0
control file sequential read 1,593 0 2 1 0.0
latch: enqueue hash chains 337 0 2 6 0.0
buffer deadlock 1,091 99 2 2 0.0
Segments by Logical Reads DB/Inst: apple22A/apple22a Snaps: 1747-1752
-> End Segment Logical Reads Threshold: 10000
-> Pct Total shows % of logical reads for each top segment compared with total
logical reads for all segments captured by the Snapshot
Subobject Obj. Logical Pct
Owner Tablespace Object Name Name Type Reads Total
TPCCDB TPCCDB NEW_ORDER TABLE 89,638,240 51.4
TPCCDB TPCCDB PK_STOCK INDEX 22,913,776 13.1
TPCCDB TPCCDB PK_ORDER_LINE INDEX 14,941,264 8.6
TPCCDB TPCCDB PK_O_ORDER INDEX 10,503,040 6.0
TPCCDB TPCCDB ORDER_LINE TABLE 6,368,896 3.7
Segments by Physical Reads DB/Inst: apple22A/apple22a Snaps: 1747-1752
-> End Segment Physical Reads Threshold: 1000
Subobject Obj. Physical Pct
Owner Tablespace Object Name Name Type Reads Total
TPCCDB TPCCDB NEW_ORDER TABLE 49 12.2
TPCCDB TPCCDB WAREHOUSE TABLE 49 12.2
TPCCDB TPCCDB DISTRICT TABLE 49 12.2
TPCCDB TPCCDB INDEX_NO_D_ID INDEX 49 12.2
TPCCDB TPCCDB PK_NEW_ORDER INDEX 49 12.2
SQL Memory Statistics DB/Inst: apple22A/apple22a Snaps: 1747-1752
Begin End % Diff
Avg Cursor Size (KB): 65.12 67.79 3.95
Cursor to Parent ratio: 1.03 1.02 -.08
Total Cursors: 560 620 9.68
Total Parents: 546 605 9.75
init.ora Parameters DB/Inst: apple22A/apple22a Snaps: 1747-1752
End value
Parameter Name Begin value (if different)
aq_tm_processes 1
audit_file_dest /rdbms/oracle/apple22i/64/admin/o
background_dump_dest /rdbms/oracle/apple22i/64/admin/o
commit_write BATCH,NOWAIT
compatible 10.2.0.1.0
control_files /rdbms/oracle/apple22i/64/oradata
core_dump_dest /rdbms/oracle/apple22i/64/admin/o
cursor_sharing EXACT
db_block_size 8192
db_domain yyyyyyy
db_file_multiblock_read_count 16
db_name apple22a
db_recovery_file_dest /rdbms/oracle/apple22i/64/flash_r
db_recovery_file_dest_size 2147483648
dispatchers (PROTOCOL=TCP) (SERVICE=apple22aX
dml_locks 30028
global_names TRUE
job_queue_processes 10
log_archive_dest_1 LOCATION=/perf0/Archivelog_10g_ch
log_archive_format arch_%t_%s_%r.dbf
log_buffer 30571520
open_cursors 300
pga_aggregate_target 524288000
processes 2000
remote_login_passwordfile EXCLUSIVE
sessions 2205
sga_max_size 3758096384
sga_target 3758096384
transactions 7507
undo_management AUTO
undo_tablespace UNDOTBS1
user_dump_dest /rdbms/oracle/apple22i/64/admin/o
-------------------------------------------------------------Process Memory Summary Stats DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> B: Begin snap E: End snap
-> All rows below contain absolute values (i.e. not diffed over the interval)
-> Max Alloc is Maximum PGA Allocation size at snapshot time
Hist Max Alloc is the Historical Max Allocation for still-connected processes
-> Num Procs or Allocs: For Begin/End snapshot lines, it is the number of
processes. For Category lines, it is the number of allocations
-> ordered by Begin/End snapshot, Alloc (MB) desc
Hist Num
Avg Std Dev Max Max Procs
Alloc Used Freeabl Alloc Alloc Alloc Alloc or
Category (MB) (MB) (MB) (MB) (MB) (MB) (MB) Allocs
B -------- 192.0 95.1 8.8 2.0 6.4 51 55 97
Other 179.0 1.8 6.3 50 54 97
Freeable 8.8 .0 .8 .6 2 11
PL/SQL 2.7 1.4 .0 .0 0 0 95
SQL 2.0 1.0 .0 .0 0 2 58
E -------- 311.2 166.7 11.3 1.4 4.3 52 55 220
Other 284.0 1.3 4.1 49 52 220
Freeable 11.4 .0 1.0 1.0 3 11
PL/SQL 10.0 5.4 .0 .0 0 0 218
SQL 5.8 2.8 .0 .0 0 2 208
Top Process Memory (by component) DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> ordered by Begin/End snapshot, Alloc (MB) desc
Alloc Used Freeabl Max Hist Max
PId Category (MB) (MB) (MB) Alloc (MB) Alloc (MB)
B 5 DBW0 -------- 51.3 22.5 1.0 51.3 54.8
Other 50.3 50.3 53.8
Freeable 1.0 .0 1.0
PL/SQL .0 .0 .0 .0
6 LGWR -------- 24.7 11.7 .1 24.7 25.5
Other 24.5 24.5 25.4
Freeable .1 .0 .1
PL/SQL .0 .0 .0 .0
16 ARC0 -------- 21.9 10.3 .0 21.9 21.9
Other 21.9 21.9 21.9
PL/SQL .0 .0 .0 .0
17 ARC1 -------- 21.9 10.3 .0 21.9 21.9
Other 21.9 21.9 21.9
PL/SQL .0 .0 .0 .0
54 TNS V1-V3 --- 4.4 1.3 1.7 4.4 4.4
Other 2.6 2.6 2.6
Freeable 1.7 .0 1.7
SQL .2 .1 .2 2.3
PL/SQL .0 .0 .0 .0
11 MMON -------- 3.5 1.6 1.3 3.5 3.6
Other 2.1 2.1 2.1
Freeable 1.3 .0 1.3
SQL .1 .0 .1 1.1
PL/SQL .0 .0 .0 .1
8 SMON -------- 2.8 .7 1.9 2.8 2.8
Freeable 1.9 .0 1.9
Other .8 .8 .8
SQL .1 .0 .1 .6
PL/SQL .0 .0 .0 .0
10 CJQ0 -------- 1.6 .6 .8 1.6 1.7
Freeable .8 .0 .8
Other .7 .7 .7
SQL .1 .0 .1 .6
PL/SQL .0 .0 .0 .0
20 q000 -------- 1.6 .7 .2 1.6 1.6
Other 1.3 1.3 1.3
Freeable .2 .0 .2
SQL .1 .1 .1 .5
PL/SQL .0 .0 .0 .0
24 ------------ 1.6 .6 .3 1.6 1.6
Other 1.2 1.2 1.2
Freeable .3 .0 .3
SQL .1 .0 .1 .6
PL/SQL .1 .0 .1 .1
7 CKPT -------- 1.4 .4 .8 1.4 2.3
Freeable .8 .0 .8
Other .6 .6 1.4
SQL .0 .0 .0 .1
PL/SQL .0 .0 .0 .0
9 RECO -------- 1.2 .5 .6 1.2 1.2
Freeable .6 .0 .6
Other .5 .5 .5
SQL .1 .1 .1 .5
Top Process Memory (by component) DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> ordered by Begin/End snapshot, Alloc (MB) desc
Alloc Used Freeabl Max Hist Max
PId Category (MB) (MB) (MB) Alloc (MB) Alloc (MB)
B 9 PL/SQL .0 .0 .0 .0
21 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .0 .0 .0 .0
SQL .0 .0 .0 .2
31 ------------ 1.1 .6 .1 1.1 1.1
Other .9 .9 .9
SQL .1 .0 .1 .2
Freeable .1 .0 .1
PL/SQL .1 .0 .1 .1
E 5 DBW0 -------- 52.4 23.4 3.3 52.4 54.8
Other 49.2 49.2 51.5
Freeable 3.3 .0 3.3
PL/SQL .0 .0 .0 .0
6 LGWR -------- 24.7 11.7 .1 24.7 25.5
Other 24.5 24.5 25.4
Freeable .1 .0 .1
PL/SQL .0 .0 .0 .0
16 ARC0 -------- 21.9 10.3 .0 21.9 21.9
Other 21.9 21.9 21.9
PL/SQL .0 .0 .0 .0
17 ARC1 -------- 21.9 10.3 .0 21.9 21.9
Other 21.9 21.9 21.9
PL/SQL .0 .0 .0 .0
54 TNS V1-V3 --- 4.6 1.3 1.9 4.6 4.6
Other 2.4 2.4 2.4
Freeable 2.1 .0 2.1
SQL .1 .1 .1 2.5
PL/SQL .0 .0 .0 .0
11 MMON -------- 3.5 1.6 1.3 3.5 3.6
Other 2.1 2.1 2.1
Freeable 1.3 .0 1.3
SQL .1 .0 .1 1.1
PL/SQL .0 .0 .0 .1
8 SMON -------- 2.8 .7 1.8 2.8 2.8
Freeable 1.8 .0 1.8
Other 1.0 1.0 1.0
SQL .1 .0 .1 .6
PL/SQL .0 .0 .0 .0
10 CJQ0 -------- 1.6 .6 .8 1.6 1.7
Freeable .8 .0 .8
Other .7 .7 .7
SQL .1 .0 .1 .6
PL/SQL .0 .0 .0 .0
20 q000 -------- 1.6 .7 .2 1.6 1.6
Other 1.3 1.3 1.3
Freeable .2 .0 .2
SQL .1 .1 .1 .5
PL/SQL .0 .0 .0 .0
24 ------------ 1.6 .6 .6 1.6 1.6
Other .9 .9 .9
Freeable .6 .0 .6
SQL .1 .0 .1 .6
Top Process Memory (by component) DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> ordered by Begin/End snapshot, Alloc (MB) desc
Alloc Used Freeabl Max Hist Max
PId Category (MB) (MB) (MB) Alloc (MB) Alloc (MB)
E 24 PL/SQL .1 .0 .1 .1
7 CKPT -------- 1.5 .4 .7 1.5 2.3
Other .8 .8 1.5
Freeable .7 .0 .7
SQL .0 .0 .0 .1
PL/SQL .0 .0 .0 .0
9 RECO -------- 1.2 .5 .6 1.2 1.2
Freeable .6 .0 .6
Other .5 .5 .5
SQL .1 .1 .1 .5
PL/SQL .0 .0 .0 .0
219 ------------ 1.2 .5 .0 1.2 1.2
Other 1.1 1.1 1.1
PL/SQL .0 .0 .0 .0
SQL .0 .0 .0 .2
21 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .0 .0 .0 .0
SQL .0 .0 .0 .2
31 ------------ 1.1 .6 .1 1.1 1.1
Other .9 .9 .9
SQL .1 .0 .1 .2
Freeable .1 .0 .1
PL/SQL .1 .0 .1 .1
205 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .1 .0 .1 .1
SQL .0 .0 .0 .1
27 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .1 .0 .1 .1
SQL .0 .0 .0 .1
158 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .1 .0 .1 .1
SQL .0 .0 .0 .1
172 ------------ 1.1 .5 .0 1.1 1.1
Other 1.0 1.0 1.0
PL/SQL .1 .0 .1 .1
SQL .0 .0 .0 .1
Enqueue activity DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> only enqueues with waits are shown
-> Enqueue stats gathered prior to 10g should not be compared with 10g data
-> ordered by Wait Time desc, Waits desc
Enqueue Type (Request Reason)
Requests Succ Gets Failed Gets Waits Wt Time (s) Av Wt Time(ms)
TX-Transaction (row lock contention)
106,475 106,474 0 106,341 20,273 190.64
TX-Transaction (index contention)
44,355 44,355 0 44,319 2,784 62.81
TX-Transaction (allocate ITL entry)
184 184 0 182 9 46.81
HW-Segment High Water Mark
1,975 1,975 0 70 5 66.29
FB-Format Block
2,164 2,164 0 50 3 54.60
TX-Transaction
394,649 394,668 0 30 0 4.33
Undo Segment Summary DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> Min/Max TR (mins) - Min and Max Tuned Retention (minutes)
-> STO - Snapshot Too Old count, OOS - Out Of Space count
-> Undo segment block stats:
uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed
eS - expired Stolen, eR - expired Released, eU - expired reUsed
Undo Num Undo Number of Max Qry Max Tx Min/Max STO/ uS/uR/uU/
TS# Blocks (K) Transactions Len (s) Concy TR (mins) OOS eS/eR/eU
1 117.7 322,423 49 73 15/15 0/0 0/0/0/0/0/0
Undo Segment Stats DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> Most recent 35 Undostat rows, ordered by End Time desc
Num Undo Number of Max Qry Max Tx Tun Ret STO/ uS/uR/uU/
End Time Blocks Transactions Len (s) Concy (mins) OOS eS/eR/eU
17-Aug 03:40 117,733 322,423 49 73 15 0/0 0/0/0/0/0/0
Latch Activity DB/Inst: apple22A/apple22a Snaps: 2147-2151
->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
Consistent RBA 3,517 0.0 0 0
FAL request queue 11 0.0 0 0
FAL subheap alocation 11 0.0 0 0
FIB s.o chain latch 20 0.0 0 0
FOB s.o list latch 361 0.0 0 0
JS mem alloc latch 2 0.0 0 0
JS queue access latch 2 0.0 0 0
JS queue state obj latch 3,706 0.0 0 0
JS slv state obj latch 16 0.0 0 0
KGX 0 0 353,668 6.5
KMG MMAN ready and start 636 0.0 0 0
KMG resize request state 27 33.3 1.0 0 0
KTF sga latch 2 0.0 0 165 0.0
KWQP Prop Status 4 0.0 0 0
MQL Tracking Latch 0 0 11 0.0
Memory Management Latch 660 0.2 0.0 0 624 0.0
OS process 294 0.0 0 0
OS process allocation 507 0.0 0 0
OS process: request allo 333 0.0 0 0
PL/SQL warning settings 270,940 0.3 0.0 0 0
SGA IO buffer pool latch 2,654 0.0 0 5,801 0.0
SQL memory manager latch 4 0.0 0 158 0.0
SQL memory manager worka 11,158 0.0 0 0
Shared B-Tree 29 0.0 0 0
active checkpoint queue 8,205 0.0 0 0
active service list 2,335 0.0 0.0 0 174 0.0
archive control 13 0.0 0 0
archive process latch 171 0.0 0 0
buffer pool 139 0.0 0 0
cache buffer handles 46,062 0.1 0.0 0 0
cache buffers chains 457,192,374 0.2 0.0 1082 3,785,637 0.6
cache buffers lru chain 447,547 0.5 0.3 8 90,454,746 2.6
cache table scan latch 0 0 11,447 0.0
cas latch 100 0.0 0 0
channel handle pool latc 333 0.0 0 0
channel operations paren 8,286 0.0 0 0
checkpoint queue latch 199,380 0.0 0.0 0 386,367 0.0
client/application info 1,208 0.0 0 0
compile environment latc 791,470 0.0 0.1 1 0
dml lock allocation 3,552,580 0.5 0.1 117 0
dummy allocation 336 0.3 0.0 0 0
enqueue hash chains 5,288,101 0.3 0.1 45 23,479 0.4
enqueues 1,120,394 0.1 0.1 2 0
event group latch 239 0.0 0 0
file cache latch 2,388 0.0 0 0
global KZLD latch for me 236 0.0 0 0
hash table column usage 0 0 4,564 0.0
hash table modification 30 0.0 0 0
job workq parent latch 0 0 4 0.0
job_queue_processes para 11 0.0 0 0
Latch Activity DB/Inst: apple22A/apple22a Snaps: 2147-2151
->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
kks stats 302 0.0 0 0
ksuosstats global area 58 0.0 0 0
ktm global data 270 0.0 0 0
kwqbsn:qsga 29 0.0 0 0
lgwr LWN SCN 3,520 0.0 0 0
library cache 19,899,407 0.4 0.0 199 16,683 ######
library cache load lock 1,030 0.0 0 63 0.0
library cache lock 17,688 0.2 0.0 0 0
library cache lock alloc 990 0.0 0 0
library cache pin 19,007,237 0.2 0.0 35 1,074 0.0
library cache pin alloca 681 0.0 0 0
list of block allocation 1,042 0.1 1.0 0 0
longop free list parent 8 0.0 0 16 12.5
messages 38,525 0.0 0.0 0 0
mostly latch-free SCN 2,543,316 0.1 0.0 0 0
multiblock read objects 30,207 0.0 1.0 0 0
ncodef allocation latch 8 0.0 0 0
object queue header heap 10 0.0 0 1,365 0.0
object queue header oper 1,198,162 0.1 0.1 0 0
object stats modificatio 832 0.0 0 0
parallel query alloc buf 64 0.0 0 0
parameter table allocati 116 1.7 0.5 0 0
post/wait queue 28,580 0.4 0.0 0 8,842 0.0
process allocation 333 0.0 0 239 0.0
process group creation 333 0.0 0 0
qmn state object latch 1 0.0 0 0
qmn task queue latch 124 0.0 0 0
redo allocation 22,668 2.0 0.2 1 9,366,319 0.5
redo copy 13 76.9 1.3 0 9,367,099 0.4
redo on-disk SCN 11,212 0.0 0 0
redo writing 23,270 0.0 0.0 0 0
resmgr group change latc 244 0.0 0 0
resmgr:actses active lis 347 0.0 0 0
resmgr:actses change gro 238 0.0 0 0
resmgr:free threads list 335 0.3 0.0 0 0
resmgr:schema config 12 0.0 0 0
rm cas latch 1,038 0.0 0 0
row cache objects 464,390 0.0 0.0 0 0
rules engine rule set st 400 0.0 0 0
sequence cache 752 0.0 0 0
session allocation 1,627,067 0.2 0.0 1 0
session idle bit 1,875,662 0.0 0.0 0 0
session state list latch 486 0.0 0 0
session switching 8 0.0 0 0
session timer 174 0.0 0 0
shared pool 58,091 0.3 0.3 1 0
simulator hash latch 32,009,012 0.0 0.0 0 0
simulator lru latch 20,996,297 4.9 0.0 1243 15,131 0.2
slave class 1 0.0 0 0
slave class create 3 0.0 0 0
Latch Activity DB/Inst: apple22A/apple22a Snaps: 2147-2151
->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
sort extent pool 100 0.0 0 0
threshold alerts latch 29 0.0 0 0
transaction allocation 965 0.0 0 0
transaction branch alloc 8 0.0 0 0
undo global data 24,845,984 0.2 0.0 20 0
user lock 658 4.4 0.9 1 0
Latch Sleep breakdown DB/Inst: apple22A/apple22a Snaps: 2147-2151
-> ordered by misses desc
Get Spin
Latch Name Requests Misses Sleeps Gets
simulator lru latch 20,996,297 1,020,829 20,140 1,003,339
cache buffers chains 457,192,374 1,016,828 24,247 994,418
library cache 19,899,407 86,387 3,201 83,529
undo global data 24,845,984 42,072 497 41,638
library cache pin 19,007,237 36,024 619 35,469
dml lock allocation 3,552,580 17,725 1,223 16,696
enqueue hash chains 5,288,101 14,754 1,086 13,773
simulator hash latch 32,009,012 7,219 54 7,171
session allocation 1,627,067 2,489 117 2,385
cache buffers lru chain 447,547 2,278 583 1,792
mostly latch-free SCN 2,543,316 1,814 14 1,802
enqueues 1,120,394 1,253 89 1,172
object queue header operat 1,198,162 1,010 52 965
PL/SQL warning settings 270,940 682 5 677
redo allocation 22,668 448 71 389
session idle bit 1,875,662 387 8 380
compile environment latch 791,470 176 12 165
shared pool 58,091 171 48 127
checkpoint queue latch 199,380 33 1 32
user lock 658 29 25 5
redo copy 13 10 13 0
KMG resize request state o 27 9 9 0
parameter table allocation 116 2 1 1
multiblock read objects 30,207 1 1 0
list of block allocation 1,042 1 1 0
-------------------------------------------------------------Edited by: praveenkumaar on Aug 18, 2009 4:07 AM -
Understanding Statistics io and Logical reads - is logical reads information correct
Hi,
This question arises during a performance test - on SQL Server 2012 with SP2.
In the following example, table has only column and that is of data type INT.
When inserted 592 records of data type INT it is doing only 1 logical read but as soon another record is inserted SP is reporting 2 logical reads. Why?
In the code, i have highlighted difference between
statistics io - logical reads and sys.dm_exec_procedure_stats.total_logical_reads
to understand the difference between these 2 information.
set nocount on
GO
create table dbo.test_storage_and_logical_reads
employee_number int --primary key
GO
go
CREATE procedure dbo.test_sp_logical_reads
as
begin
select
employee_number
from dbo.test_storage_and_logical_reads
order by employee_number desc
end
go
insert into dbo.test_storage_and_logical_reads
(employee_number)
VALUES (1)
GO 592
EXEC sp_spaceused 'dbo.test_storage_and_logical_reads'
--set statistics io on
--GO
exec dbo.test_sp_logical_reads
GO
----Table 'test_storage_and_logical_reads'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
---- But sys.dm_exec_procedure_stats.total_logical_reads is reporting 3 instead.
truncate table dbo.test_storage_and_logical_reads
GO
insert into dbo.test_storage_and_logical_reads
(employee_number)
VALUES (1)
GO 593
EXEC sp_spaceused 'dbo.test_storage_and_logical_reads'
exec dbo.test_sp_logical_reads
GO
----Table 'test_storage_and_logical_reads'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
---- But sys.dm_exec_procedure_stats.total_logical_reads is reporting 4 instead.
--drop procedure dbo.test_sp_logical_reads
--drop table dbo.test_storage_and_logical_reads
GO
NB: I do understand the logical and physical reads. Thanks.
For quick review of new features, try virtual labs: http://msdn.microsoft.com/en-us/aa570323Hi.
I still need to test the scenario but if you read definition of this DMV it says 'Returns aggregate performance statistics for cached stored procedures' so I guess, I am not sure 3 can be due to this aggregated output given by this DMV. Will test it
on SS 2012 SP2 will get back to you.
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it.
My TechNet Wiki Articles
Hi Shanky / Sean Gallardy
i think Sean Gallardy created the "test_sp_logical_reads" table in master DB, i have that same issue when i accidentiatly created the table "test_sp_logical_reads" in master, but when i create the same table in USER DB like "sample1"
it only allocate 1 page for 592,
hi Asam,
Let me narrow down the your question, if my understanding is correct ...
<<When you have the free space in a page of a Heap, why SQL Server is assigning New page for a New Record>>
Answer is in PFS bytes
The answer is that PFS bytes are not fully reset until the page is reallocated. On deallocation, the only bit in the PFS byte that's changed is the allocation status bit - this makes it very easy to rollback a deallocation
--Before inserting the 593 record plese execute the below query
--Note Replace "database1" with your DBName
DBCC TRACEON (3604);
DBCC IND ('database1', 'test_storage_and_logical_reads', 1);
--Result
PageFID PagePID IAMFID IAMPID ObjectID IndexID PartitionNumber PartitionID iam_chain_type PageType IndexLevel NextPageFID NextPagePID PrevPageFID PrevPagePID
1 2770 NULL NULL 517576882 0 1 72057594039828480 In-row data 10 NULL 0 0 0 0
1 2769 1 2770 517576882 0 1 72057594039828480 In-row data 1 0 0 0 0 0
--your intrested in the second record(page)
DBCC PAGE ('database1', 1, 2769,3) WITH TABLERESULTS;
--you can find 38th row as
--PFS (1:1) = 0x64 MIXED_EXT ALLOCATED 100_PCT_FULL
--which means your page is full
--you can try inserting 300 rows it will show you PFS (1:1) = 0x61 MIXED_EXT ALLOCATED 50_PCT_FULL
please refer in the below link
http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/07/08/under-the-covers-gam-sgam-and-pfs-pages.aspx
http://aboutsqlserver.com/2013/12/17/sql-server-storage-engine-heap-tables/
"This page has a PFS byte value of 0x04 - how can it be full when its not allocated?"
The answer is that PFS bytes are not fully reset until the page is reallocated. On deallocation, the only bit in the PFS byte that's changed is the allocation status bit - this makes it very easy to rollback a deallocation.
Here's an example. Using a database with a simple table with one row.
A DBCC PAGE of the IAM page includes:
PFS (1:1) = 0x70 IAM_PG MIXED_EXT ALLOCATED 0_PCT_FULL
If I run the following:
BEGIN
TRANSACTION
DROP
TABLE T1
GO
And then do the DBCC PAGE again, the output now includes:
PFS (1:1) = 0x30 IAM_PG MIXED_EXT 0_PCT_FULL
And if I rollback then transaction, the DBCC PAGE output reverts to:
PFS (1:1) = 0x70 IAM_PG MIXED_EXT ALLOCATED 0_PCT_FULL
Thanks
Saravana Kumar C -
Corruption Parameters Increase High Physical Read for one query
Hi Oracle Experts,
Here is what I am currently facing in my non-prod environment:
We are testing out corruption parameters in non-prod environment and doing a perf test for them and we found that one SELECT query has seen significant decreases in performance; What I mean by that is after adding corruption parameters query is executing 40 sec compare to 18 sec and less. Also, this query is widely use by user in Prod environment, so performance degradation will create serious impact on their work.
I have generated AWR Diff for baseline and perf test following are parameter we have set for corruption test:
db_block_checking (Baseline) LOW (Perftest) MEDIUM
db_block_checksum (Baseline) TRUE (Perftest) FULL
Load Profile from AWR Diff are below:
Load Profile
1st Per Sec 2nd Per Sec %Diff 1st Per Txn 2nd Per Txn %Diff
Redo size: 758,356.06 752,760.94 -0.74 67,161.76 66,631.71 -0.79
Logical reads: 104,637.62 108,677.76 3.86 9,266.95 9,619.77 3.81
Block changes: 1,578.11 1,560.15 -1.14 139.76 139.76 0.00
Physical reads: 103.78 544.41 424.58 9.19 48.19 424.37
Physical writes: 108.94 107.13 -1.66 9.65 9.48 -1.76
User calls: 3,477.02 3,497.26 0.58 307.93 309.57 0.53
Parses: 948.36 949.61 0.13 83.99 84.06 0.08
Hard parses: 0.79 0.54 -31.65 0.07 0.05 -28.57
Sorts: 121.48 120.32 -0.95 10.76 10.65 -1.02
Logons: 0.36 0.27 -25.00 0.03 0.02 -33.33
Executes: 1,575.55 1,591.40 1.01 139.53 140.87 0.96
Transactions: 11.29 11.30 0.09
If we gather stats for tables involved in the query than it performs well in fact with in 5 Sec, but I believe in prod we can't gather state very often.
Questions:
1) How to remedy this situation and have query perform well along with corruption parameters?
2) Does corruption parameters have impact on SELECT query too, I believe it will have impact on INSERT and UPDATE.
3) Any reference to Doc will be highly appreciated.1) How to remedy this situation and have query perform well along with corruption parameters?Use faster CPU. Checksum is a thing that needs to be computed.
2) Does corruption parameters have impact on SELECT query too, I believe it will have impact on INSERT and UPDATE.According to docs corruption parameters do not have impact on SELECT queries.
However, I believe, checksum has to be recomputed after delayed block cleanout that may be done by SELECT query after big update. ( http://jonathanlewis.wordpress.com/2009/06/16/clean-it-up/ )
3) Any reference to Doc will be highly appreciated.
Why is it difficult for you to find the docs yourself? -
Problem:
1.
If you run a SQL code and you read the logical reads. is it benefit for performance issue to have low value of logical reads not matter what?
2.
What is the definition of logical reads?'
Im a beginner in performance tuningLogical reads is a metric that can be used to evaluate query plans. Less logical reads is usually better. However, it's not the best metric, that's wallclock time, in my opinion. Particularly, looking blindly on logical reads, may lead you to think that
a plan with lots of CPU-expensive hashing operations are better than a simpler plan with nested loop joins.
The nice thing with logical reads over wallclock time, is that logical reads is not affected by other operations on the server.
OP, overall I agree with Erland, all other things being equal, less logical reads is better than more logical reads.
But sometimes other things are not all equal - it does you little good to trade logical reads for a ton of CPU instead!
However, logical reads *are* affected, dramatically, by other operations on the server - they are not as purely "logical" as one might like! If your buffers are empty and you have to do physical IO to get the data, even the *logical* reads shows higher
numbers! Exactly why this is the case is obscure, or complicated, or something, but it is. Similarly even contention with other processes especially for buffer space can affect the "logical" reads to a small or larger extent.
But the good news is that sometimes logical reads are really, really cheap, so sometimes you can get a query that does 100,000 logical reads but runs in a tenth of second anyway. Whether it's worth a battle to cut the logical reads down then, is up
to you.
HTH,
Josh -
Sudden increase in buffer gets per executions in update statement
Hi,
Recently we have encountered one performance issue, which is most likely caused by a sudden increase in the buffer gets per execution.
The SQL is an update statement, updating a table using a primary key (we have checked to confirm the running execution plan is using the primary key), and one field being updated is a BLOB column.
As shown in the below statistics, there is no major change in the number of executions during the every 20 minutes monitoring interval. However, the buffer gets per executions has been more than double, and the CPU time is almost doubled, hence the exec_time (elapsed time) has been doubled.
The same SQL has been running for the past four years in multiple similar databases. The database is Oracle 9.2.0.4 running on Solaris 9. For the past 300 days, the average elapsed time per execution is about 0.0093s, while the average buffer gets per execution is about 670. The update statement has been executed about 9 times per second.
The question is why there is a sudden increase in the buffer gets? The sudden increase happened twice for the past two days.
<pre>
B_TIME E_TIME EXECUTIONS_DIFF EXEC_TIME CPU_TIME BUFFER_GETS EXEC_PER_DAY
2009-11-25-14:04 2009-11-25-14:23 8513 .0069 .0068 315.56 646329
2009-11-25-14:23 2009-11-25-14:43 10170 .007 .0068 312.28 726188
2009-11-25-14:43 2009-11-25-15:05 11873 .0072 .0069 320.17 787885
2009-11-25-15:05 2009-11-25-15:23 8633 .011 .0101 844.83 675014
2009-11-25-15:23 2009-11-25-15:44 9668 .0144 .0137 1448.51 680778
2009-11-25-15:44 2009-11-25-16:04 9671 .0163 .0156 1809.04 702163
2009-11-25-16:04 2009-11-25-16:25 10260 .0188 .0177 2107.67 711447
2009-11-25-16:25 2009-11-25-16:44 9827 .0157 .0151 1834.3 739593
2009-11-25-16:44 2009-11-25-17:05 10586 .0171 .0164 2008.25 714555
2009-11-26-08:04 2009-11-26-08:24 11028 .0182 .0172 1979.61 800688
2009-11-26-08:24 2009-11-26-08:44 10533 .0154 .0149 1734.62 750248
2009-11-26-08:44 2009-11-26-09:04 9367 .018 .0168 2043.95 685274
2009-11-26-09:04 2009-11-26-09:24 10307 .0214 .0201 2552.43 729938
2009-11-26-09:24 2009-11-26-09:45 10932 .0251 .0234 3111.48 762328
2009-11-26-09:45 2009-11-26-10:05 10992 .0278 .0254 3386.41 797404
2009-11-26-15:03 2009-11-26-15:16 7183 .0425 .0348 4615.42 746824
2009-11-26-15:16 2009-11-26-15:23 2921 .0417 .0373 4887.75 682092
2009-11-26-15:23 2009-11-26-15:43 9597 .0393 .0352 4603.62 679656
2009-11-26-15:43 2009-11-26-16:03 8797 .0411 .0362 4783.66 630755
2009-11-26-16:03 2009-11-26-16:23 9957 .0453 .0391 5168.28 718100
2009-11-26-16:23 2009-11-26-16:43 11209 .0436 .0369 4870.77 808395
2009-11-26-16:43 2009-11-26-17:03 10729 .0428 .0375 5119.56 766103
2009-11-26-17:03 2009-11-26-17:23 9116 .0409 .0363 4912.58 659098
</pre>
Yesterday I did a trace on one of the sessions running the update statement, and below is the tkprof output:
<pre>
call count cpu elapsed disk query current rows
Parse 76 0.03 0.00 0 0 0 0
Execute 76 4.58 5.14 0 567843 19034 76
Fetch 0 0.00 0.00 0 0 0 0
total 152 4.61 5.14 0 567843 19034 76
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 88
Rows Row Source Operation
1 UPDATE (cr=30 r=0 w=0 time=6232 us)
1 INDEX UNIQUE SCAN <PK Index Name> (cr=3 r=0 w=0 time=58 us)(object id 81122)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
Waited--------------------------------------------------------------------------------
SQL*Net message to client 152 0.00 0.00
SQL*Net message from client 152 0.00 0.22
SQL*Net more data from client 1894 0.00 0.03
SQL*Net break/reset to client 152 0.00 0.00
buffer busy waits 14 0.00 0.00
enqueue 1 0.61 0.61
</pre>
GaoYuanHi,
I've reformatted your output for better understanding (with {noformat}...{noformat}):
B_TIME E_TIME EXECUTIONS_DIFF EXEC_TIME CPU_TIME BUFFER_GETS EXEC_PER_DAY
2009-11-25-14:04 2009-11-25-14:23 8513 .0069 .0068 315.56 646329
2009-11-25-14:23 2009-11-25-14:43 10170 .007 .0068 312.28 726188
2009-11-25-14:43 2009-11-25-15:05 11873 .0072 .0069 320.17 787885
2009-11-25-15:05 2009-11-25-15:23 8633 .011 .0101 844.83 675014
2009-11-25-15:23 2009-11-25-15:44 9668 .0144 .0137 1448.51 680778
2009-11-25-15:44 2009-11-25-16:04 9671 .0163 .0156 1809.04 702163
2009-11-25-16:04 2009-11-25-16:25 10260 .0188 .0177 2107.67 711447
2009-11-25-16:25 2009-11-25-16:44 9827 .0157 .0151 1834.3 739593
2009-11-25-16:44 2009-11-25-17:05 10586 .0171 .0164 2008.25 714555
2009-11-26-08:04 2009-11-26-08:24 11028 .0182 .0172 1979.61 800688
2009-11-26-08:24 2009-11-26-08:44 10533 .0154 .0149 1734.62 750248
2009-11-26-08:44 2009-11-26-09:04 9367 .018 .0168 2043.95 685274
2009-11-26-09:04 2009-11-26-09:24 10307 .0214 .0201 2552.43 729938
2009-11-26-09:24 2009-11-26-09:45 10932 .0251 .0234 3111.48 762328
2009-11-26-09:45 2009-11-26-10:05 10992 .0278 .0254 3386.41 797404
2009-11-26-15:03 2009-11-26-15:16 7183 .0425 .0348 4615.42 746824
2009-11-26-15:16 2009-11-26-15:23 2921 .0417 .0373 4887.75 682092
2009-11-26-15:23 2009-11-26-15:43 9597 .0393 .0352 4603.62 679656
2009-11-26-15:43 2009-11-26-16:03 8797 .0411 .0362 4783.66 630755
2009-11-26-16:03 2009-11-26-16:23 9957 .0453 .0391 5168.28 718100
2009-11-26-16:23 2009-11-26-16:43 11209 .0436 .0369 4870.77 808395
2009-11-26-16:43 2009-11-26-17:03 10729 .0428 .0375 5119.56 766103
2009-11-26-17:03 2009-11-26-17:23 9116 .0409 .0363 4912.58 659098
call count cpu elapsed disk query current rows
Parse 76 0.03 0.00 0 0 0 0
Execute 76 4.58 5.14 0 567843 19034 76
Fetch 0 0.00 0.00 0 0 0 0
total 152 4.61 5.14 0 567843 19034 76
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 88
Rows Row Source Operation
1 UPDATE (cr=30 r=0 w=0 time=6232 us)
1 INDEX UNIQUE SCAN <PK Index Name(cr=3 r=0 w=0 time=58 us)(object id 81122)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
SQL*Net message to client 152 0.00 0.00
SQL*Net message from client 152 0.00 0.22
SQL*Net more data from client 1894 0.00 0.03
SQL*Net break/reset to client 152 0.00 0.00
buffer busy waits 14 0.00 0.00
enqueue 1 0.61 0.61
********************************************************************************Can you please provide a DDL for the table, indexes, type of the tablespace(s) they reside in (ASSM/MSSM, extents sizes), the UPDATE statement, how many sessions on average/peaks are doing the same thing concurrently, how many sessions are working this table concurrently and how do they use it? -
Logic to get customer balance confirmation at profit center level.
Hi All
Please help me understand the logic to get customer balance confirmation at profit center level.(not at company codewhichis available)
On what basis developments can be done.
Detailed and early Inputs will be appreciated
Thanks in advance.
vadapavHi
First of all, I liked your user name...
I have a basic question with regards to your requirement... Customer is an external party... he has got nothing to do with your internal definition of profit centers..
Hence, if Customer A is buying goods from you belonging to Pr Ctr B and C - He wlil expect you to send a balance conf letter which aggregates total balance... He will be, in no way, concerned with your internal division of profit center wise balance
Still, if you would like to go ahead with your requirement , then identify the open line items from BSID or BSAD (I dont know which one of these stores open line items) , Take that document no to table FAGLFLEXA and identify your profit center... This is assuming you are on ECC 6.0 and use New GL
If you are not on ECC 6.0, then identify the open line items from BSID or BSAD and Take that document no to table BSEG and read the profit center from revenue line item.. These revenue accounts can be included in a SET created in GS01 rather than hard coding in the program
Regards
Ajay M -
What is Exact logic to get BOM ITEM
Hi all,
BOm Item retrival logic is giving item ,But checked in CS03 there is no BOM ITEM present for that material and plant combination.
Tried with FM 'CSAP_MAT_BOM_ITEM_SELECT 'and BAPI ' CSAP_MAT_BOM_READ' to get Material BOM ITEM...Its working perfect and not giving any Item.....its correct output.
But I dont want to use BAPI and FM.
Please let me know anyone...what is Exact logic to get ITEM.
My logic involves MAST -> STKO -> STAS -> STPO.
Edited by: amit soni on Aug 26, 2011 11:15 AMNot pretty sure what you need. My guess is that you want to know the link between the table related to BOM master and for some reason don't want to use the FM or BAPI.
MAST -> Matnr (mat), werks (plant), stlan (bom usage), stlal (alt.bom #), you will get the stlnr (internal bom number). Note that if you have multiple BOM, you will get the same alt bom#.
STKO -> Use stlty (BOM Category = M Material), stlnr (BOM#), stlal (alt BOM#), you get the BOM header.
STAS -> stlty (BOM Category = M Material), stlnr (BOM#), stlal (Alt BOM#), you get the STLKN ( item node)
STPO -> stlty (BOM Category = M Material), stlnr (BOM#), stlkn (item node), you get the right item from the BOM header specified.
Hope this is what you want. -
Subtype authorisation of "GET PERAS"
Can "GET PERAS" authority check by subtype?
For example..
I create a authorisation about the use can read just "IT0006 subtype 1".
I can check "IT0006 subtype 1" in pa30.
But I can't check "IT0006 subtype 1" in report program which program use "GET PERAS."
I think that if I don't have all subtype authorisation I can't check the infotype record by "GET PEARS".
Is it a specification?
Message was edited by:
Makoto NishiwakiHello Patricia
The problem here is that you are using your ZMMBUS2012 in your workflow. You should use the original business object BUS2012.
Have you remembered to delegate your new subtype to BUS2012 ? (you do this in trx SWO1 Settings -> Delegate).
When you have done this, your new attributes/methods will be "inherited" from your subtype ZMMBUS2012 to BUS2012, and they will be availabel on the original object - BUS2012 - in your workflow.
Regards
Morten Nielsen -
Logical reads VS physical reads
hello all,
What is the difference between logical reads and physical read ??? I do get the part of logical read (from buffer) and physical read(from disk). And also do know physical reads are bad, but is it true in oracle world..logical reads are bad ??? if so why ??? Could you please explain which on to look for. As i am going thru AWR report and i see segemts by logical/physical read.The first and foremost difference is that physcial reads are done from the hard disk. And this is always going tobe slwoer than the memory. That's why its said that the physcial ios must be removed. Logical ios are good as they are done from the memory.The theory that logical are also not good is because the logical ios require the access given by latches. So with lots of the gets for the latches put them in to contention and latch contention would make the access to the logical io slower.So its better to do this in less IO even they are logical too.
Lots of logical IOs probably mean that you are accessing unnecessary data which may be not required.
HTH
Aman.... -
Scan count 17 logical reads 176543 showing in execution plan
Hello,
I am getting scan count 17 and logical reads 145634 and some time the query takes 2 minutes and sometime 5 seconds.Thelogical reads showing against a big table(Product and Orders) that is having 10 milions records.After procedure executed it gives only 7008
records as out put.
SELECT Cust.Name
FROM dbo.Customers Cust WITH (NOLOCK)
INNER JOIN Products Prod WITH (NOLOCK) ON Cust.ID = Prod.CustID
INNER JOIN dbo.Orders Ords WITH (NOLOCK) on Cust.RepID = prod.ProdId
INNER JOIN dbo.[Address] Adds WITH (NOLOCK) on Prod.id = Adds.Id
WHERE ords.pickeddate between @startdate and @enddate
Please do the needful.>>>>How to reduce logical reads against big tables?
Have a useful index/s . But please show the execution plan of the query as David pointed.
Best Regards,Uri Dimant SQL Server MVP,
http://sqlblog.com/blogs/uri_dimant/
MS SQL optimization: MS SQL Development and Optimization
MS SQL Consulting:
Large scale of database and data cleansing
Remote DBA Services:
Improves MS SQL Database Performance
SQL Server Integration Services:
Business Intelligence
Maybe you are looking for
-
Doubt Regarding validation of IDOCS
Hi Gurus, I have some doubts regarding IDOCS. 1. If we are sending a IDOC from XI to R/3, where does we do validations from R/3 side and how do we do that. Suppose if we are sending a Purchase order IDOC form XI to R/3, how to do validati
-
Hello everybody. I'm trying to make an XMLDocument from a String with the next context I have read from a file: <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE ReporteHoras SYSTEM "ReporteHoras.dtd"><ReporteHoras><Persona nombre="Daniel"><Fecha dia="
-
Why do we need the @EJB annotation at the class level?
Why do we need the @EJB annotation at the class level? Eg: Why do we need the first piece of code, when the second code seems much simpler . *1.* @Stateful @EJB(name="ejb/TradeLocalNm", beanInterface=TradeLocal.class) public class TradeClientBean imp
-
i can't connect to my youtube or wifi, youtube is popping up and saying "cannot connect to youtube" and wifi is saying I'm entering the wrong password. Please help
-
How to Report a Broken Web Site?
How do I report a broken web site? If I click on 'Help', I do not see 'Report Broken Web Site.' I am using Mozilla Firefox 4.0b8 on Windows XP SP3.