Physical reads in Database
Dear Experts,
I need to pull distinct SQL IDs for the SQLs run by a particular user - "PROD" b/w 9am - 5pm ( snap IDs 1000 - 1008). I wrote below SQL:
select distinct sql_id from DBA_HIST_SQLSTAT where PARSING_SCHEMA_NAME = 'PROD' and snap_id between 1000 and 1008
Does anyone see a reason why this can be wrong?
Thanks for sharing inputs.
Ora DBA wrote:
Dear Experts,
I need to pull distinct SQL IDs for the SQLs run by a particular user - "PROD" b/w 9am - 5pm ( snap IDs 1000 - 1008). I wrote below SQL:
select distinct sql_id from DBA_HIST_SQLSTAT where PARSING_SCHEMA_NAME = 'PROD' and snap_id between 1000 and 1008
Does anyone see a reason why this can be wrong?
Thanks for sharing inputs.SQL statements are NOT associated with any particular USER; which is why they reside in the SHARED Global Area.
Similar Messages
-
Logical read Vs Physical Reads
Hi,
I want to know How should we balance the logical reads and physical reads on database.
I generaly assume logical reads is always better but what if too many session accessing the same
objects it will cause latch contention.
If it is physical read then it will take more time to read from disk than reading from SGA.
If I look at statspack report I check the
Logical reads: 59,846.54 840.03
Physical reads: 1,095.91 15.38
Is there any standards for logical reads on database. If there is latch contentions can we go for the
decreasing the SGA to avoid the contentions so that there will balance between the physical reads
and logical reads.amitbansode wrote:
I want to know How should we balance the logical reads and physical reads on database.There is no balance as it implies some kind of "+perfect ratio+" for logical I/O vs. physical I/O.
A high percentage of physical I/O can be perfectly acceptable and normal and correct for a specific database (e.g. think of a system collecting telemetry data where 90% or more of all I/O is writing new telemetry into the database and the remaining 10% is querying the data, with old data being aged out from the database using partition drops which is negligible I/O).
A high percentage of logical I/O can be indicative of a serious application design problem - where 80GB of database data is read and read again and again and again.. resulting in over a TB of logical I/O. (actually saw this in production database some years ago)
So there is no balance (e.g. not true that physical I/O = BAD and logical I/O = GOOD). No perfect cache hit ratio figure that tells you that the database is doing the right amounts of logical and physical I/O.
And I want to emphasise what Mark said - tuning requires you to identify the performance problem first, before trying to solve it.
It is very dangerous to take one metric, like the I/O cache hit ratio, and attempt to tune that. It alone is meaningless. Just like memory utilisation alone is useless and CPU utilisation alone is useless. It does not by any means point to an actual performance problem. E.g. 100% CPU utilisation can mean hardware has insufficient horses, instead of performance issues related with application design, database setting or kernel configuration.
I often repeat the following mantra here on OTN - a fundamental concept IMO for software engineering:
A solution is only as good as the problem definition.
Identify the problem first - correctly and comprehensively. And then solve it. -
Can we run application services when physical stand by database is in read
can we run application services when physical stand by database is in read only mode
i Want to up the EBS application services and check login when phyiscal standby database is in read only mode.
Is it possible? for checking dataguard database application as well.but i just want to know that can i start EBS application services and nagivate the application.Without distrubing my primary database and application.You should not do as the moment you open the standby database it becomes invalid.
Thanks,
Hussein -
What causes BUFFER GETS and PHYSICAL READS in INSERT operation to be high?
Hi All,
Am performing a huge number of INSERTs to a newly installed Oracle XE 10.2.0.1.0 on Windows. There is no SELECT statement running, but just INSERTs one after the other of 550,000 in count. When I monitor the SESSION I/O from Home > Administration > Database Monitor > Sessions, I see the following stats:
BUFFER GETS = 1,550,560
CONSISTENT GETS = 512,036
PHYSICAL READS = 3,834
BLOCK CHANGES = 1,034,232
The presence of 2 stats confuses. Though the operation is just INSERT in database for this session, why should there be BUFFER GETS of this magnitude and why should there by PHYSICAL READS. Aren't these parameters for read operations? The BLOCK CHANGES value is clear as there are huge writes and the writes change these many blocks. Can any kind soul explain me what causes there parameters to show high value?
The total columns in the display table are as follows (from the link mentioned above)
1. Status
2. SID
3. Database Users
4. Command
5. Time
6. Block Gets
7. Consistent Gets
8. Physical Reads
9. Block Changes
10. Consistent Changes
What does CONSISTENT GETS and CONSISTENT CHANGES mean in a typical INSERT operation? And does someone know which all tables are involved in getting these values?
Thank,
...Flake wrote:
Hans, gracias.
The table just have 2 columns, both of which are varchar2 (500). No constraints, no indexes, neither foreign key references are in place. The total size of RAM in system is 1GB, and yes, there are other GUI's going on like Firefox browser, notepad and command terminals.
But, what does these other applications have to do with Oracle BUFFER GETS, PHYSICAL READS etc.? Awaiting your reply.Total RAM is 1GB. If you let XE decide how much RAM is to be allocated to buffers, on startup that needs to be shared with any/all other applications. Let's say that leaves us with, say 400M for the SGA + PGA.
PGA is used for internal stuff, such as sorting, which is also used in determing the layout of secondary facets such as indexes and uniqueness. Total PGA usage varies in size based on the number of connections and required operations.
And then there's the SGA. That needs to cover the space requirement for the data dictionary, any/all stored procedures and SQL statements being run, user security and so on. As well as the buffer blocks which represent the tablespace of the database. Since it is rare that the entire tablespace will fit into memory, stuff needs to be swapped in and out.
So - put too much space pressure on the poor operating system before starting the database, and the SGA may be squeezed. Put that space pressure on the system and you may enbd up with swapping or paging.
This is one of the reasons Oracle professionals will argue for dedicated machines to handle Oracle software. -
Query on data dictionary results in large number of physical reads
I don't understand why I am getting 80,000 physicals for this query. I am not looking for help re-writing this. I just don't understand why I would hit the disk at all.
My understanding had been that v$views where sql structures that pointed to x$tables. These x$tables are sql structures.
underneath, the x$tables were linked lists stored in memory. This is why when you bounce the database, all the data, gets reset. Since it is not saved to disk.
I am doing a simple insert/select off of v$open_cursor that is resulting in 80,000+ physical reads. I am posting the tkprof. It is all from v$open_cursor.
mysid_table has 6 records. It is 1 mb in size
if I index mysid_table.sid the query reduces to 20,000 physical reads. (but all the physical reads are on v$session_event)
the sequence number I am passing returns 2 SIDs
insert into my_save_table
select *
from v$session_event
where sid in (select sid
from my_sid_table
where id = vseq);
vrowcount := sql%rowcount;
call count cpu elapsed disk query current rows
Parse 1 0.01 0.01 0 0 0 0
Execute 1 31.70 47.57 88570 22 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 31.71 47.58 88570 22 0 1
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 22
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
latch: row cache objects 1 0.00 0.00
log file sync 1 0.00 0.00
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
********************************************************************************It seems like there is some missing information.
You have a wait for a log file sync, but no commit.
Your table my_sid_table is 1 MB for only 6 records?
Does the target table you are inserting into (my_save_table) have indexes on it? -
High no. of physical reads of a query in statspack report
we have a Oracle database 9.2.0.6 on solaris box....
SQL ordered by Reads for DB: ic Instance: ic12 Snaps: 19 -20
-> End Disk Reads Threshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
1,103,253 77 14,328.0 53.1 1641.98 11428.17 3825541888
Module: w3wp.exe
select MRH_MRN,DECODE(MRH_SEX,'M','MALE','FEMALE') AS SEX, trim
((mrh_sur_name||' '||mrh_first_name||' '||mrh_middle_name)) as M
EMNAME, decode(nvl(mrh_fellow_status_yn,'333'),'Y','FCA','ACA')
AS ACA_FCA, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ADDR_LINE_1,'A',
MRH_RES_ADDR_LINE_1) AS L_ADD1, DECODE(MRH_RESI_STATUS,'I',MRH_Pexplain plan
SQL> explain plan for select MRH_MRN,DECODE(MRH_SEX,'M','MALE','FEMALE') AS SEX
, trim((mrh_sur_name||' '||mrh_first_name||' '||mrh_middle_name)) as MEMNAME, de
code(nvl(mrh_fellow_status_yn,'333'),'Y','FCA','ACA')AS ACA_FCA, DECODE(MRH_RESI
_STATUS,'I',MRH_PROF_ADDR_LINE_1,'A',
2 MRH_RES_ADDR_LINE_1) AS L_ADD1, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ADDR_LI
NE_2,'A',MRH_RES_ADDR_LINE_2) AS L_ADD2, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ADD
R_LINE_3,'A',MRH_RES_ADDR_LINE_3) ASL_ADD3, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_
ADDR_LINE_4,'A',
3 MRH_RES_ADDR_LINE_4) AS L_ADD4, DECODE(MRH_RESI_STATUS,'I',a.city_name,'A',
C.CITY_NAME) AS L_CITY, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ZIP_POSTAL_CODE,'A',
MRH_RES_ZIP_POSTAL_CODE) AS L_PIN, DECODE(MRH_RESI_STATUS,'I',b.cou_name,'A',D.C
OU_NAME) as L_Country,
4 DECODE(MRH_RESI_STATUS,'I','NOT APPLICABLE',MRH_PROF_ADDR_LINE_1)AS R_ADD1,
DECODE(MRH_RESI_STATUS,'I',' ',MRH_PROF_ADDR_LINE_2)AS R_ADD2, DECODE(MRH_RESI_
STATUS,'I',' ',MRH_PROF_ADDR_LINE_3)
5 AS R_ADD3, DECODE(MRH_RESI_STATUS,'I',' ',MRH_PROF_ADDR_LINE_4)AS R_ADD4, D
ECODE(MRH_RESI_STATUS,'I',' ','A',A.CITY_NAME) AS R_CITY, DECODE(MRH_RESI_STATUS
,'I',' ','A',MRH_PROF_ZIP_POSTAL_CODE) AS R_PIN, DECODE(MRH_RESI_STATUS,'I',' ',
'A',B.COU_NAME) as
6 R_Country, decode(nvl(mrh_mem_sub_status,'555'),'26','EXPIRED','') as sub_s
tatus, decode(nvl(mrh_mem_status,'777'),'1','ACTIVE','2','REMOVED') as mem_statu
s,mrh_resi_status, DECODE(MRH_COP_STATUS,'1',DECODE(MRH_COP_TYPE ,'13','FULLTIME
-COP','1',
7 'FULLTIME-COP', '12','PARTTIME-COP','2','PARTTIME-COP'),'NOT HOLDING COP')
AS COP_STATUS, TO_CHAR(MRH_ENROL_DT,'RRRR') AS ASSO_YR,TO_CHAR(MRH_FELLOW_DT,'RR
RR') AS FELLOW_YR from om_mem_reg_head,om_city A,
8 om_country B,om_city C,om_country D where mrh_doc_status=5 and mrh_prof_
city_code=A.City_code(+) and mrh_prof_cou_code=B.cou_code(+) and mrh_res_city_c
ode=C.City_code(+) and mrh_res_cou_code=D.cou_code(+) and trim((mrh_sur_name||'
'||mrh_first_name||
9 ''||mrh_middle_name)) like upper('%%') ORDER BY trim((mrh_sur_name||' '||m
rh_first_name||' '||mrh_middle_name))
10 ;
Explained.
SQL> select * from table(dbms_xplan.displaY());
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost
|
| 0 | SELECT STATEMENT | | 2870 | 762K| | 202
PLAN_TABLE_OUTPUT
8 |
| 1 | SORT ORDER BY | | 2870 | 762K| 1592K| 202
8 |
| 2 | NESTED LOOPS OUTER | | 2870 | 762K| | 190
2 |
| 3 | NESTED LOOPS OUTER | | 2870 | 714K| | 190
2 |
PLAN_TABLE_OUTPUT
| 4 | HASH JOIN OUTER | | 2870 | 667K| | 190
2 |
| 5 | HASH JOIN OUTER | | 2870 | 616K| | 189
2 |
| 6 | TABLE ACCESS FULL| OM_MEM_REG_HEAD | 2870 | 566K| | 188
2 |
| 7 | TABLE ACCESS FULL| OM_COUNTRY | 677 | 12186 | |
4 |
PLAN_TABLE_OUTPUT
| 8 | TABLE ACCESS FULL | OM_COUNTRY | 677 | 12186 | |
4 |
| 9 | INDEX UNIQUE SCAN | CITY_CODE_PK | 1 | 17 | |
|
| 10 | INDEX UNIQUE SCAN | CITY_CODE_PK | 1 | 17 | |
|
PLAN_TABLE_OUTPUT
Note: cpu costing is off, PLAN_TABLE' is old version
18 rows selected.
SQL>Please suggest me whjat cab done to overcome the same
Edited by: user00726 on Feb 3, 2009 5:03 AMSQL> show arraysize
arraysize 15
SQL>should i set SDU parameter in tnsnames and listener.ora
for more info related to the same...pls do visit the below thread:
n/w perfromance related problem -
Oracle 9i Performance Issue High Physical Reads
Dear All,
I have Oracle 9i Release 9.2.0.5.0 database under HP Unix, I have run the query and got following output. Can any body just have a look and advise what to do in the following situation? We have performance issues.
Many thanks in advance
Buffer Pool Advisory for DB: DBPR Instance: DBPR End Snap: 902
-> Only rows with estimated physical reads >0 are displayed
Size for Size Buffers for Est Physical Estimated
P Estimate (M) Factr Estimate Read Factor Physical Reads
D 416 .1 51,610 4.27 1,185,670,652
D 832 .2 103,220 2.97 825,437,374
D 1,248 .3 154,830 2.03 563,139,985
D 1,664 .4 206,440 1.49 412,550,232
D 2,080 .5 258,050 1.32 366,745,510
D 2,496 .6 309,660 1.23 340,820,773
D 2,912 .7 361,270 1.14 317,544,771
D 3,328 .8 412,880 1.09 301,680,173
D 3,744 .9 464,490 1.04 288,191,418
D 4,096 1.0 508,160 1.00 276,929,627Hi,
Actually you didnt give the exact problem statement.
Seems to be your database is I/O bound. Ok, do the following one by one:
1. Identify the FTS queries and try to create the optimal indexes (depending on the disk reads factor!!) on the problem queries.
2. To reduce the 276M physical reads, you need to allocate more memory to db_cache_size. try 8GB (initially) and then depending on the buffer advisery you can increase further if you have more memory on the box.
3. as a Next step , configure KEEP and RECYCLE cache to get the benefits of reduced I/O by multiple pools. Allocate objects to the KEEP/RECYCLE pools.
Thanks, -
I 'm running the same query against two databases on two different servers, and not seeing the expected results.
Query runs in 6 seconds on server A, and 32 seconds on server B. The database on B is a copy of the database on A, same blocksize, same db_file_multiblock_read_count.
Query is:
SELECT
IMS_BO_PMAN08.REF_ID,( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC Expenditure','V','ACQ Expenditure')
FROM
IMS_BO_PMAN08,
IMS_BO_PMAN08_TRAN
WHERE
( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID )
AND ( IMS_BO_PMAN08.VERSION_ID IN (select version_id from ims_bo_version where version_id = 1 ) )
AND ( IMS_BO_PMAN08.INV_REGION_CODE > 2 )
and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast') ='Actual'
GROUP BY
IMS_BO_PMAN08.REF_ID,decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC Expenditure','V','ACQ Expenditure');
I am seeing the same execution plan when running the query against either database, with the same cost in each case. However, the physical reads on server B is ten times that of on server A
Server A
=====
293851 rows selected.
Elapsed: 00:00:06.58
Execution Plan
0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=50270 Card=27811 Bytes=973385)
1 0 SORT (GROUP BY) (Cost=50270 Card=27811 Bytes=973385)
2 1 HASH JOIN (Cost=50088 Card=27811 Bytes=973385)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'IMS_BO_PMAN08' (Cost=17990 Card=26243 Bytes=446131)
4 3 INDEX (RANGE SCAN) OF 'IMS_BO_PMAN08_IX1' (UNIQUE) (Cost=105 Card=26243)
5 2 NESTED LOOPS (Cost=32049 Card=107258 Bytes=1930644)
6 5 INDEX (UNIQUE SCAN) OF 'IMS_BO_VERSION_IX1' (UNIQUE)
7 5 TABLE ACCESS (FULL) OF 'IMS_BO_PMAN08_TRAN' (Cost=32048 Card=107258 Bytes=1716128)
Statistics
0 recursive calls
13 db block gets
288529 consistent gets
*18,218 physical reads*
0 redo size
17924295 bytes sent via SQL*Net to client
2174914 bytes received via SQL*Net from client
19592 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
293851 rows processed
Server B
=====
292677 rows selected.
Elapsed: 00:00:32.66
Execution Plan
0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=50255 Card=27805 Bytes=973175)
1 0 SORT (GROUP BY) (Cost=50255 Card=27805 Bytes=973175)
2 1 HASH JOIN (Cost=50073 Card=27805 Bytes=973175)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'IMS_BO_PMAN08' (Cost=17984 Card=26237 Bytes=446029)
4 3 INDEX (RANGE SCAN) OF 'IMS_BO_PMAN08_IX1' (UNIQUE) (Cost=105 Card=26237)
5 2 NESTED LOOPS (Cost=32040 Card=107230 Bytes=1930140)
6 5 INDEX (UNIQUE SCAN) OF 'IMS_BO_VERSION_IX1' (UNIQUE)
7 5 TABLE ACCESS (FULL) OF 'IMS_BO_PMAN08_TRAN' (Cost=32039 Card=107230 Bytes=1715680)
Statistics
0 recursive calls
357 db block gets
250918 consistent gets
*188,332 physical reads*
0 redo size
17853447 bytes sent via SQL*Net to client
2166145 bytes received via SQL*Net from client
19513 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
292677 rows processed
8.1.6.3 on solaris 8
Can anyone tell me where the excessive physical i/o's (and presumably associated runtime) is coming from? Any pointers much appreciated.
Pete
Edited by: user12248598 on 17-Mar-2010 09:01sort_area_size, sort_area_retained_size & hash_area_size are the same size for both instances, as are all NLS settings.
Tables are not specified NOCACHE, and there are no additional buffer pools.
Running with sql_trace enabled for both queries highlighed some very interesting results:
For the slow query, this is the tkprof output, unfortunately waits=yes is not available in 8.1.6
TKPROF: Release 8.1.6.3.0 - Production on Tue Mar 23 14:54:18 2010
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Trace file: imsroc_ora_10166.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
alter session set events '10046 trace name context forever, level 8'
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 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
BEGIN DBMS_APPLICATION_INFO.SET_MODULE(:1,NULL); END;
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.01 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.01 0.01 0 0 0 1
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
SELECT
IMS_BO_PMAN08.REF_ID,
( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup
','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Comple
tions','F','FC Expenditure','V','ACQ Expenditure')
FROM
bo_ims.IMS_BO_PMAN08,
bo_ims.IMS_BO_PMAN08_TRAN
WHERE ( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID )
AND ( IMS_BO_PMAN08.VERSION_ID IN (select version_id from bo_ims.ims_bo_version where version_id =
1 ) )
AND ( IMS_BO_PMAN08.INV_REGION_CODE > 2 )
and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast') = 'Actual'
GROUP BY
IMS_BO_PMAN08.REF_ID,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup
','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Comple
tions','F','FC Expenditure','V','ACQ Expenditure')
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 16278 15.36 36.39 215625 251560 361 244156
total 16280 15.36 36.39 215625 251560 361 244156
Misses in library cache during parse: 0
Optimizer goal: FIRST_ROWS
Parsing user id: 5
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 3 0.01 0.01 0 0 0 1
Fetch 16278 15.36 36.39 215625 251560 361 244156
total 16283 15.37 36.40 215625 251560 361 244157
Misses in library cache during parse: 1
Misses in library cache during execute: 1
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
3 user SQL statements in session.
0 internal SQL statements in session.
3 SQL statements in session.
Trace file: imsroc_ora_10166.trc
Trace file compatibility: 8.00.04
Sort options: default
2 sessions in tracefile.
5 user SQL statements in trace file.
0 internal SQL statements in trace file.
3 SQL statements in trace file.
3 unique SQL statements in trace file.
75998 lines in trace file.And this is the tkprof formatted output for the faster running query:
TKPROF: Release 8.1.6.3.0 - Production on Tue Mar 23 14:56:28 2010
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Trace file: imslive_ora_7489.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
alter session set events '10046 trace name context forever, level 8'
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 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
SELECT
IMS_BO_PMAN08.REF_ID,
( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,:SYS_B_00,:SYS_B_01,:SYS_B_02,:SYS_B_03),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,:SYS_B_04,:SYS_B_05,:SYS_B_06,:SYS_B_07,:SYS_B_08,:SYS_B_09,:SYS_B_10,:
SYS_B_11,:SYS_B_12,:SYS_B_13,:SYS_B_14,:SYS_B_15,:SYS_B_16,:SYS_B_17,:SYS_B_18,:SYS_B_19,:SYS_B_20,:SYS_B_21,:
SYS_B_22,:SYS_B_23)
FROM
BO_IMS.IMS_BO_PMAN08,
BO_IMS.IMS_BO_PMAN08_TRAN
WHERE ( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID )
AND ( IMS_BO_PMAN08.VERSION_ID IN (select version_id from bo_ims.ims_bo_version where version_id = :SYS_B_
24 ) )
AND ( IMS_BO_PMAN08.INV_REGION_CODE > :SYS_B_25 )
and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,:SYS_B_26,:SYS_B_27,:SYS_B_28,:SYS_B_29) = :SYS_B_30
GROUP BY
IMS_BO_PMAN08.REF_ID,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,:SYS_B_31,:SYS_B_32,:SYS_B_33,:SYS_B_34),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,:SYS_B_35,:SYS_B_36,:SYS_B_37,:SYS_B_38,:SYS_B_39,:SYS_B_40,:SYS_B_41,:
SYS_B_42,:SYS_B_43,:SYS_B_44,:SYS_B_45,:SYS_B_46,:SYS_B_47,:SYS_B_48,:SYS_B_49,:SYS_B_50,:SYS_B_51,:SYS_B_52,:
SYS_B_53,:SYS_B_54)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 20042 0.00 0.00 20064 295221 13 300608
total 20045 0.00 0.00 20064 295221 13 300608
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
Rows Row Source Operation
300608 SORT GROUP BY
300628 NESTED LOOPS
55647 NESTED LOOPS
2 INDEX UNIQUE SCAN (object id 151050)
55647 TABLE ACCESS BY INDEX ROWID IMS_BO_PMAN08
55649 INDEX RANGE SCAN (object id 185149)
300628 TABLE ACCESS BY INDEX ROWID IMS_BO_PMAN08_TRAN
356274 INDEX RANGE SCAN (object id 157241)
DELETE FROM PLAN_TABLE
WHERE
STATEMENT_ID=:1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 3 5 12 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 3 5 12 0
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
Rows Row Source Operation
1 DELETE PLAN_TABLE
1 TABLE ACCESS FULL PLAN_TABLE
EXPLAIN PLAN SET STATEMENT_ID='PLUS18028884' FOR SELECT
IMS_BO_PMAN08.REF_ID,
( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','S
OS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC E
xpenditure','V','ACQ Expenditure')
FROM
BO_IMS.IMS_BO_PMAN08,
BO_IMS.IMS_BO_PMAN08_TRAN
WHERE ( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID )
AND ( IMS_BO_PMAN08.VERSION_ID IN (select version_id from bo_ims.ims_bo_version where version_id = 1 ) )
AND ( IMS_BO_PMAN08.INV_REGION_CODE > 2 )
and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast') = 'Actual'
GROUP BY
IMS_BO_PMAN08.REF_ID,
decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','S
OS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC E
xpenditure','V','ACQ Expenditure')
call count cpu elapsed disk query current rows
Parse 1 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 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5
insert into plan_table (statement_id, timestamp, operation, options,
object_node, object_owner, object_name, object_instance, object_type,
search_columns, id, parent_id, position, other,optimizer, cost, cardinality,
bytes, other_tag, partition_start, partition_stop, partition_id,
distribution )
values
(:1,SYSDATE,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16,:17,:18,:19,
:20,:21,:22)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 7 0.00 0.00 1 3 9 7
Fetch 0 0.00 0.00 0 0 0 0
total 8 0.00 0.00 1 3 9 7
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 5 (recursive depth: 1)
select o.name, u.name
from
sys.obj$ o, sys.user$ u where obj# = :1and owner# = user#
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 3 12 0 2
total 5 0.00 0.00 3 12 0 2
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS (recursive depth: 1)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 3 0.00 0.00 0 0 0 0
Execute 4 0.00 0.00 3 5 12 0
Fetch 20042 0.00 0.00 20064 295221 13 300608
total 20049 0.00 0.00 20067 295226 25 300608
Misses in library cache during parse: 3
Misses in library cache during execute: 1
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 9 0.00 0.00 1 3 9 7
Fetch 2 0.00 0.00 3 12 0 2
total 13 0.00 0.00 4 15 9 9
Misses in library cache during parse: 2
5 user SQL statements in session.
1 internal SQL statements in session.
6 SQL statements in session.
Trace file: imslive_ora_7489.trc
Trace file compatibility: 8.00.04
Sort options: default
3 sessions in tracefile.
8 user SQL statements in trace file.
1 internal SQL statements in trace file.
6 SQL statements in trace file.
6 unique SQL statements in trace file.
77410 lines in trace file.The sql statement as run did not make use of bind variables, so the ones in the tkprof output for the longer running statement made me immediately think of cursor sharing, and right there in the init.ora for the faster running database was CURSOR_SHARING=FORCE.
I'm not familiar with the history of the databases, nor the specific reasoning for enabling cursor sharing (bind variable usage seems prevalent in all custom code) so I've replicated the setting on the slower database, resulting in a similar tkprof output to the faster server, with a runtime of 7 seconds for 2nd and subsequent runs.
My immediate issue is now solved, thanks to all who contributed, and apologies for not spotting the obvious earlier.
Regards, Pete -
No of physical reads of buffers from disk on PROD and Clone has huge differ
Please help !
I am having a problem interpreting a tkprof report.
I am executing the same statement below in PROD and Clone of PROD.
What I do not understand why the tkprof report shows huge difference in disk reads for same executions from PROD and Clone of PROD. I.e. first execution disk reads = 757187 , second = 6.
I expected to see Similar disk reads in the second execution also.The data it fetches is same in both the Instances.
Statment
SELECT NVL(SUM(RG_OTH.DEBIT),0),NVL(SUM(RG_OTH.CREDIT),0)
FROM
JA_IN_PLA PLA,JAI_RG_OTHERS RG_OTH,HR_ALL_ORGANIZATION_UNITS HOU,
HR_LOCATIONS LOC,JA_IN_HR_ORGANIZATION_UNITS HR_ORG WHERE 1 = 1 AND
PLA.ORGANIZATION_ID = :b1 AND TRUNC(PLA.CREATION_DATE) >= :b2 AND
TRUNC(PLA.CREATION_DATE) <= :b3 AND HOU.ORGANIZATION_ID =
PLA.ORGANIZATION_ID AND LOC.LOCATION_ID = PLA.LOCATION_ID AND
HR_ORG.ORGANIZATION_ID = PLA.ORGANIZATION_ID AND HR_ORG.LOCATION_ID =
PLA.LOCATION_ID AND TRANSACTION_ID = 19 AND INVENTORY_ITEM_ID != 0 AND
NVL(ROUNDING_ID,1) != -1 AND RG_OTH.SOURCE_REGISTER_ID = PLA.REGISTER_ID
AND RG_OTH.SOURCE_REGISTER = 'PLA' AND RG_OTH.TAX_TYPE IN (
'EXCISE_EDUCATION_CESS' )
Tkproff from PROD.
call count cpu elapsed disk query current rows
Parse 1 0.01 0.01 0 0 0 0
Execute 1 0.04 0.03 0 0 0 0
Fetch 1 973.41 1724.95 757187 789442 0 1
total 3 973.46 1725.01 757187 789442 0 1
Tkproff from CLONE of PROD.
call count cpu elapsed disk query current rows
Parse 1 0.06 0.05 1 789 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.73 0.72 6 30594 0 1
total 3 0.79 0.78 7 31383 0 1wins wrote:
SELECT NVL(SUM(RG_OTH.DEBIT),0),NVL(SUM(RG_OTH.CREDIT),0)
FROM
JA_IN_PLA PLA,JAI_RG_OTHERS RG_OTH,HR_ALL_ORGANIZATION_UNITS HOU,
HR_LOCATIONS LOC,JA_IN_HR_ORGANIZATION_UNITS HR_ORG WHERE 1 = 1 AND
PLA.ORGANIZATION_ID = :b1 AND TRUNC(PLA.CREATION_DATE) >= :b2 AND
TRUNC(PLA.CREATION_DATE) <= :b3 AND HOU.ORGANIZATION_ID =
PLA.ORGANIZATION_ID AND LOC.LOCATION_ID = PLA.LOCATION_ID AND
HR_ORG.ORGANIZATION_ID = PLA.ORGANIZATION_ID AND HR_ORG.LOCATION_ID =
PLA.LOCATION_ID AND TRANSACTION_ID = 19 AND INVENTORY_ITEM_ID != 0 AND
NVL(ROUNDING_ID,1) != -1 AND RG_OTH.SOURCE_REGISTER_ID = PLA.REGISTER_ID
AND RG_OTH.SOURCE_REGISTER = 'PLA' AND RG_OTH.TAX_TYPE IN (
'EXCISE_EDUCATION_CESS' )
Tkproff from PROD.
call count cpu elapsed disk query current rows
Parse 1 0.01 0.01 0 0 0 0
Execute 1 0.04 0.03 0 0 0 0
Fetch 1 973.41 1724.95 757187 789442 0 1
total 3 973.46 1725.01 757187 789442 0 1
Tkproff from CLONE of PROD.
call count cpu elapsed disk query current rows
Parse 1 0.06 0.05 1 789 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.73 0.72 6 30594 0 1
total 3 0.79 0.78 7 31383 0 1
As others have pointed out, this looks like a change in execution plan. At a guess, the PROD database is doing a tablescan somewhere (physical reads is approximately equal to logical reads is a pointer).
There are many reasons why this could happen, continuing with the guesswork - we note that the statement was re-optimised (hard parsed) in the clone, but used an existing cursor in production (logical I/O = 0 in prod, 789 in clone). So the plan you got in the clone was the one that Oracle thought best for the inputs you had supplied. The plan in prod could have been produced as the response to a completely different set of input; since you have two bind variables applied to a range based predicated and one bind variable with equality it's possible that you have a histogram that makes a difference on the equality column, alternatively the range of dates used to generate the original plan was very different from the range used in the test.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b> -
Error 9 reading message database during Expire Maintenance
I have scheduled maintenance to perform an expire on my post office
Processing information for this run:
Path to PO = servername/mail:\groupwse\wcicc_po
Post Office= WCICC_POST
User = All
Action = Expire
Age Limit = Thursday, July 1, 2010 - 8:00 pm (60 days)
Trash Limit = 15 days
- Exp items = mail, calendar, doc refs, Inbox, Outbox
Verbose = Yes
Upd DiskSpace= No
Output log = servername/mail:\groupwse\wcicc_po\wpcsout\chk\gwexpire.log
I keep receiving the following error
================================================== ==============================
===== TASK LOG - 1305 (4c7c134e.ckl) ===========================================
================================================== ==============================
Checking for items matching purge criteria
Error 9- MESSAGE database read error BAD_IX (0xC00E)
Suggestion- Check physical consistency of database, rebuild if errors found
PROCESSING COMPLETED- total processing time: 0:00:00
================================================== ==============================
===== JOB LOG SUMMARY (4c7c0dcd.ckl) ===========================================
================================================== ==============================
*** User databases found: 1049
*** Total bytes reclaimed: 37799936
*** Average per database: 36034
Processing completed
***** OVERALL STATS FOR THIS RUN *****
Uncorrectable conditions encountered:
CODE DESCRIPTION COUNT
9 Errors reading message databases................... 1
Correctable conditions encountered:
CODE DESCRIPTION COUNT
39 Unrecognized or invalid files in mail directories.. 2
66 GWCheck log files in log directory................. 1
What message databse is this?
The previous lines show that msg254.db processing completed without errors. When I look in ofmsg directory, 254 is the last message database.
Thanks for any help.lfeltswcicc,
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
Has your problem been resolved? If not, you might try one of the following options:
- Visit http://support.novell.com and search the knowledgebase and/or check all
the other self support options and support programs available.
- You could also try posting your message again. Make sure it is posted in the
correct newsgroup. (http://forums.novell.com)
Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.novell.com/faq.php
If this is a reply to a duplicate posting, please ignore and accept our apologies
and rest assured we will issue a stern reprimand to our posting bot.
Good luck!
Your Novell Product Support Forums Team
http://forums.novell.com/ -
Adding Temp tablespace to physical stand by database?
I am getting the below error when i try to load data using SQL loader from physical stand by database to another database after making the physical stand by database in read only mode.
ORA-25153: Temporary Tablespace is Empty.
On primary database when i query
SQL>select ts#,name from v$tablespace;
TS# NAME
2 TEMP
On physical stand by when i query
SQL>select ts#,name from v$tablespace;
TS# NAME
2 TEMP
On primary DB when i query
select name from v$tempfile where ts#=2;
NAME
/dev/vx/rdsk/oradata/tempfile0101
On standby when i query
SQL>select name from v$tempfile where ts#=2;
no rows selected
At this point do i need to add datafile to the TEMP tablespace of stand by database or just need to add TEMP tablespace to stand by database.?
DB version:9.2.0.6
Thank You all...Can you make sure that /dev/vx/rdsk/oradata/tempfile0101 is copied to standby site during the standby creation. Often it happens that the hot backups are copied to standby ste and generally they dont contain temp files. If the files is present , then i'll suggest you to do a quick bounce of standby instance to make sure that controlfile attempted to access it. You can also try recreating the standby control file on promary and copy it to standby site along with the tempfile and start the instance with new control file.
If you want to add temp files to the standby instance, the only option you have is to add them on primary site. If you have standby_file_management as auto they will get copied over. If not you can copy the files to standby instance and restart the recovery.
Please let us know if any of the hints are applicable to your case.
-Ravi -
High user input output (I/O) and physical reads
Hi guys
Recently we have noticed that our database performance degraded significantly. as we looked around in grid control we noticed that the user IO and Physical reads are really high which cause the database to be laggy.
at first we thought it was memory problem, so we added 2gb to sga. we have set sga to be automatic and it's been like this for the past 2 years.
how do i trouble shoot this problem. i haven't found any troubleshooting guide for it yet.
please instruct me on how to solve it
database: 10.2.0.4 sparc
regards
SinaTop 5 Timed events
db file sequential read 23,582 679 29 46.3 User I/O
CPU time 626 42.7
db file scattered read 3,089 70 23 4.8 User I/O
db file parallel write 3,478 28 8 1.9 System I/O
log file parallel write 4,201 24 6 1.7 System I/O
SGA Memory Summary
SGA regions Begin Size (Bytes) End Size (Bytes) (if different)
Database Buffers 2,768,240,640 2,835,349,504
Fixed Size 2,050,240
Redo Buffers 14,721,024
Variable Size 3,657,439,040 3,590,330,176
Process Memory Summary
Category Alloc (MB) Used (MB) Avg Alloc (MB) Std Dev Alloc (MB) Max Alloc (MB) Hist Max Alloc (MB) Num Proc Num Alloc
B Other 569.22 0 2.62 3.14 22 24 217 217
Freeable 101.63 0.00 0.77 0.45 3 132 132
SQL 91.51 45.35 0.44 0.76 4 78 209 192
PL/SQL 12.50 5.57 0.06 0.07 0 4 217 217
JAVA 5.40 5.38 1.08 0.09 1 2 5 5
E Other 603.20 3.03 3.62 22 24 199 199
SQL 115.21 64.78 0.60 1.67 21 78 191 182
Freeable 112.31 0.00 0.83 0.43 3 135 135
PL/SQL 13.89 5.94 0.07 0.12 1 4 199 199
JAVA 8.93 8.89 1.12 0.23 2 2
for some reason i can't paste a table into this post but if you want i can email you above tables -
No physical reads, plenty of consistant gets
Hi All,
Oracle v11.2 on Linux.
Please have a look at the query I ran and the output. The SQL_ID is of a SELECT command.
What does this situation represents, where there are zero physical reads and plenty of consistant gets ?
For consistant gets, we do read undo information (correct ??), if that undo is read from disk, will that be a "physical read"? i.e. if we read disks for consistant gets, will that be counted under physical reads or not ?
How can I describe the exact data retrival of the command here? Is it the case of "everything it needs is found in the buffer cache" ?
select a.sid, a.value , B.NAME , s.sql_id
from v$sesstat a, v$statname b, v$session s
where A.STATISTIC# = B.STATISTIC#
and b.name in ( 'redo size','physical read bytes','physical reads cache','consistent gets' )
and a.sid = s.sid
and a.sid=1018
order by a.sid;
SID VALUE NAME SQL_ID
1018 7281396 consistent gets 434u36htuz0s9
1018 0 physical reads cache 434u36htuz0s9
1018 0 physical read bytes 434u36htuz0s9
1018 4448 redo size 434u36htuz0s9
4 rows selected.Thanks in advance.>
There are no physical reads, so weather its doing consistant-gets or not, can I say, all data required for the SELECT was in buffer cache ?
>
The data for those system views is cached in memory so Oracle does not read the disk (except at startup) to gather the information.
Some static information, like dictionary objects, is stored stored on disk in the system tablespace but this data is read when the database is mounted and stored in memory structures.
Other dynamic information, like session info, is only stored in memory structures (similar to C arrays) and Oracle can query these as if they were tables.
So no, the data was not in the buffer cache. It was already in system memory. -
Unable to reduce Physical Reads
Hi
Problem:
Need to reduce the Physical reads in Oracle 8.1.7
Information:
Optimizer_mode= Choose
Statistics will not be gathered.
Intially the cache hit ratio is 18%. At this point when we checked the SQL Statement
SELECT a32,
F_DOCNUMBER,NVL(a109,'BIWS') AS WorkFlow,
a147 AS Service_Subsidary,
a89 AS StaffInd,
a88 AS SubsidiaryInd
FROM doctaba
WHERE a94 = 'CCOC_CARDS_CCA_060824_6'
AND a40 IN ('3','4','5')
0 recursive calls
81 db block gets
5020 consistent gets
3909 physical reads
0 redo size
401 bytes sent via SQL*Net to client
311 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed.
Once we increase the Buffer Cache Hit Ratio to 90% We got the following
0 recursive calls
81 db block gets
3717 consistent gets
3576 physical reads
0 redo size
401 bytes sent via SQL*Net to client
311 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed.
But can you please advice how to reduce the Physical Reads further.
Note: Table DOCTABA is a Snapshot that is present in Other Database.
Please advice!!
Cheers
Ramkannan.ABuffer hit cache ratios are totally meaningless as was proven many years ago by Connor's brilliant little utility that allows you to dial in any ratio you want.
The reason your are getting FTEs is because your totally antiquated version of the product, never supported during the current century, is that it thinks FTEs cost less than using any indexes that may (or may not) exist. You've not established in your email that there are any indexes or posted DDL or provided much of anything else that would be helpful.
I would think moving from the Jurassic to 10.2.0.4, or above, would be your first priority. -
Is RMAN I/Os accounted in physical reads stat?
I mean, do the blocks read from disk by RMAN to backup the database get accounted in physical reads statistic?
One of our databases has a value for physical read total IO requests higher than physical reads so I guess the physical reads missing are RMAN's.
Thanks in advanceStatistics have not the same unit so you cannot compare them directly:
>
physical read total IO requests
Number of read requests which read one or more database blocks for all instance activity including application, backup and recovery, and other utilities. The difference between this value and "physical read total multi block requests" gives the total number of single block read requests.
>
and
>
physical reads
Total number of data blocks read from disk. This value can be greater than the value of "physical reads direct" plus "physical reads cache" as reads into process private buffers also included in this statistic.
>
You should compare physical read total IO requests with:
>
physical read IO requests
Number of read requests for application activity (mainly buffer cache and direct load operation) which read one or more database blocks per request. This is a subset of "physical read total IO requests" statistic.
>
Edited by: P. Forstmann on 9 avr. 2013 12:57
Maybe you are looking for
-
Need information on running Oracle stored procedures from VB using ODP
Hi. I'm trying to run some complex queries on a list of Oracle databases from a VB application using ODP. I've been able to execute simple queries formatted as strings on all 150 databases with no problems. Now, however the queries are more than 100
-
I have an Imac bought less than two years ago. This morning when i turned on my computer i found a white line around 4cm in the middle of my screen. What should i do? Should i change the flat panel? Is it normal for apple product to have a quality is
-
Fraud emails help required!
-
Need help in loading Data file
I am new to HFM. I am trying one example and try to load data file. But i am getting error saying period July is invalid. Do i have to follow certain steps before loading data file. Sample file !Column_Order = Scenario, Year, Period, View, Entity, Va
-
Final Cut Server tells me field name existing, but I can't see it
I'd like to create a new field with the name 'Product'. When I try to save FCS says: "There is already a field with PAMD_CUSTPRODUCT". I looked everywhere, but I can't find a field with PAMD_CUSTPRODUCT. Can someone explain to me what is going on? Th