Oracle Performance problem in Tru64 Unix

Hello All,
I am having performance problem in Tru6u Unix. Details are mentioned below :
OS: Tru64 Unix
Oracle Version : 8.1.7.4.0
Forms : 6.0
Mode: Oracle Parallel Server
When, developers are trying to save some data using forms, it's taking too much time.
Any hint/idea, how to start tracking the things, will be highly appreciated.
Regards,
Rajeev Tomar

Check what are the session waits from v$session_wait and try to tune them.
If possible, get the code and tune the sqls.
Without knowing the application behaviour and other related stuff, no one can simple adice on performance problems.
Jaffar

Similar Messages

Install Oracle 8.1.7 (TRU64 UNIX 5.1)

Need information on how to initate the istallation of Oracle
Software on TRU64 UNIX 5.1. Prior to 8.1.7, the "orainst" shell
for UNIX was used from the command line. The installation
instructions for 8.1.7 require the setting of the variable
DISPLAY, and the execution of the script "runInstaller". For
what I can tell, the new installation routine requires X-windows
to run, but I cannot figure out how to set it up.
Thank you in advance for any help on this subject.
Eduardo Bedoya

Dirk:
I had the same problem, which is caused by a
wrong version of Java. Follow the instructions
in Denis Claric's Oracle page:
http://staff.in2.hr/denis/oracle/
BUT do NOT install the RPM packages from the
RH7.1 CD-ROMs, get them from RedHat's web site instead.
-Ramon

Oracle performance problem -

We are facing some critical performance problems with one of the
tables. I have a table with the schema given below.When there
are around 2 lakh entries in this table, if I give a select count
(*) , it takes around 20 seconds to return the count. Where as
any other table in the same database, returns the count in less
than 2 seconds for around 1 lakh entries. I am not able to
figure out where the performance bottle neck is.
Configuration:
Oracle 8.0.5 on Windows NT 4.0
USER_NAME NOT NULL VARCHAR2(30)
TASK_ID NUMBER // Unique
TASK_NAME NOT NULL VARCHAR2(100)
TERMINAL_NAME VARCHAR2(30)
TASK_DATE DATE
TASK_STATUS NOT NULL NUMBER
PARENT_ID NUMBER
NE_NAME NOT NULL VARCHAR2(30)
ENM_JOBID VARCHAR2(30)
CMD_CONTENT VARCHAR2(4000)
CMD_RESPONSE VARCHAR2(4000)
RESPONSE_TIME DATE
TASK_TYPE NUMBER
SCHEDULE_TIME DATE
All the tables are present in the same table space. So
I guess it could not be because of any disk access differences
between tables. Have you guys faced any such problems ? Could
this be because of the huge CMD_RESPONSE and CMD_CONTENT
fields ?

Thanks a lot.
I would like to know , how I can optimise the performance when
having longer records. Will increasing the block size help in
getting better performance ? If so,is there any other
disadvantage in increasing the block size.
My actual requirement is to read all the records in the
table. So, a static cursor is created on the server and I do a
block fetch(SQLFetchScrolll). I use ODBC for this purpose. The
first fetch takes a lot of time, around 50 seconds or so for 2
lakh records. Any ideas how to optimise the same ???
Best Regards,
Vignesh

When can we download the Oracle 10g for HP Tru64 Unix?

Hi,
Could you tell me the time to release the HP Tru64 Unix version?
Thanks

Check this: http://otn.oracle.com/software/products/database/oracle10g/index.html
Joel Pérez

Problems with Tru64 UNIX 5.1b PCI-GPIB driver development

I am using your NI488.DDK product to develop a PCI-GPIB device driver for Tru64 UNIX 5.1b3. I have experience porting other device driver from 4.x to 5.1b and thought that this would not be too hard. The driver that I have developed loads and configures ok. It allows for the IBFIND of /dev/gpib0 minor #255 to work fine because a bus table is built for it during the probe/attach. When I try an IBFIND on /dev/gpib_dev/dev1 I get an error from ni_Cp2BusPtr for minor #51 because no table is created for the devx devices during driver initialization. I don't see where this was done in the example ib.c code provided for Tru64 Unix 4.x, am I missing something?

This is really an update to my original posting for those of you who may have similar concerns.
The source code provided as part of the NI488DDK kit is not really a fully functional driver with the same capabilities as they provided in the device driver that they devloped for Tru64 UNIX 3.x and 4.x. The the "ib" commands supported by the DDK driver is a subset of the entire ni488 suite. None of the device specific "ib" command are supported, neither is ibask. Device commands are written to the bus as character strings that contain device addresses and command.

Performance problem with Oracle

We are currently getting a system developed in Unix/Weblogic/Tomcat/Oracle environment. We have developed a screen that contains 5 or 6 different parameters to select from. We could select multiple parameters in each of these selections. The idea behind the subsequent screens is to attach information to already existing data/ possible future data that matches the selection criteria.
Based on these selections, existing data located within the system in a table is searched and those that match are selected. Also new rows are created in the table against combinations that do not currently have a match. Frequently multiple parameters are selected, and 2000 different combinations need to be searched in the table. Of these selections, only about 100 or 200 combinations will be available in existing data. So the system is having to insert 1800 rows. The user meanwhile waits for the system to come up with data based on their selections. The user is not willing to wait more than 30 seconds to get to the next screen. In the above mentioned scenario, the system takes more than an hour to insert the new records and bring the information up. We need suggestions to see if the performance can be improved this drastically. If not what are the alternatives? Thanks

The #1 cause for performance problems with Oracle is not using it correctly.
I find it hard to believe that with the small data volumes mentioned, that you can have perfornance problems.
You need to perform a sanity check. Are you using Oracle correctly? Do you know what bind variables are? Are you using indexes correctly? Are you using PL/SQL correctly? Is the instance setup correctly? What about storage, are you using SAME (RAID10) or something else? Etc.
Facts. Oracle peforms exceptionally well. Oracle exceptionally well.
Simple example from a benchmark I did on this exact same subject. App-tier developers not understanding and not using Oracle correctly. Incorrect usage of Oracle doing a 100,000 SQL statements. 24+ minutes elapsed time. Doing those exact same 100,000 SQL statement correctly (using bind variables) - 8 seconds elapsed time. (benchmark using Oracle 10.1.0.3 on a Sunfire V20z server)
But then you need to use Oracle correctly. Are you familiar with the Oracle Concepts Guide? Have you read the Oracle Application Developer Fundamentals Guide?

Unix Hardware and Oracle Performance question

Hi,
I've got Oracle v.8.1.7.4 running my database on a unix box. I don't have access to the box and wanted to know what SQL statements I could use to determine the specs of the box as we are having performance problems. Also, I am trying to determine the best scripts to use that will tell me:
1. the database's current size
2. the size of the rollback segments (used and unused)
3. any other helpful information to determine where there may be deficits in the database.
Thanks for any help you can provide!!!

This is a useful link
http://www.ixora.com.au/

Interactive report performance problem over database link - Oracle Gateway

Hello all;
This is regarding a thread Interactive report performance problem over database link that was posted by Samo.
The issue that I am facing is when I use Oracle function like (apex_item.check_box) the query slow down by 45 seconds.
query like this: (due to sensitivity issue, I can not disclose real table name)
SELECT apex_item.checkbox(1,b.col3)
, a.col1
, a.col2
FROM table_one a
, table_two b
WHERE a.col3 = 12345
AND a.col4 = 100
AND b.col5 = a.col5
table_one and table_two are remote tables (non-oracle) which are connected using Oracle Gateway.
Now if I run above queries without apex_item.checkbox function the query return or response is less than a second but if I have apex_item.checkbox then the query run more than 30 seconds. I have resolved the issues by creating a collection but it’s not a good practice.
I would like to get ideas from people how to resolve or speed-up the query?
Any idea how to use sub-factoring for the above scenario? Or others method (creating view or materialized view are not an option).
Thank you.
Shaun S.

Hi Shaun
Okay, I have a million questions (could you tell me if both tables are from the same remote source, it looks like they're possibly not?), but let's just try some things first.
By now you should understand the idea of what I termed 'sub-factoring' in a previous post. This is to do with using the WITH blah AS (SELECT... syntax. Now in most circumstances this 'materialises' the results of the inner select statement. This means that we 'get' the results then do something with them afterwards. It's a handy trick when dealing with remote sites as sometimes you want the remote database to do the work. The reason that I ask you to use the MATERIALIZE hint for testing is just to force this, in 99.99% of cases this can be removed later. Using the WITH statement is also handled differently to inline view like SELECT * FROM (SELECT... but the same result can be mimicked with a NO_MERGE hint.
Looking at your case I would be interested to see what the explain plan and results would be for something like the following two statements (sorry - you're going have to check them, it's late!)
WITH a AS
(SELECT /*+ MATERIALIZE */ *
FROM table_one),
b AS
(SELECT /*+ MATERIALIZE */ *
FROM table_two),
sourceqry AS
(SELECT b.col3 x
       , a.col1 y
       , a.col2 z
FROM table_one a
    , table_two b
WHERE a.col3 = 12345
AND   a.col4 = 100
AND   b.col5 = a.col5)
SELECT apex_item.checkbox(1,x), y , z
FROM sourceqry
WITH a AS
(SELECT /*+ MATERIALIZE */ *
FROM table_one),
b AS
(SELECT /*+ MATERIALIZE */ *
FROM table_two)
SELECT apex_item.checkbox(1,x), y , z
FROM table_one a
    , table_two b
WHERE a.col3 = 12345
AND   a.col4 = 100
AND   b.col5 = a.col5If the remote tables are at the same site, then you should have the same results. If they aren't you should get the same results but different to the original query.
We aren't being told the real cardinality of the inners select here so the explain plan is distorted (this is normal for queries on remote and especially non-oracle sites). This hinders tuning normally but I don't think this is your problem at all. How many distinct values do you normally get of the column aliased 'x' and how many rows are normally returned in total? Also how are you testing response times, in APEX, SQL Developer, Toad SQLplus etc?
Sorry for all the questions but it helps to answer the question, if I can.
Cheers
Ben
http://www.munkyben.wordpress.com
Don't forget to mark replies helpful or correct ;)

Does Oracle 8.1.5 Run On Tru64 Unix 5.1

Does Oracle 8.1.7 Run On Tru64 Unix 5.1
We plan to upgrade the OS and Oracle in two steps.
1. First weekend - upgrade the operating system from Tru64 4.0d to Tru64 5.1.
2. Second weekend - upgrade Oracle from 8.1.5 to 8.1.7
Questions:
1. Will Oracle 8.1.5 run successfully on Tru64 5.1 during the one-week transition period?
2. Does it make any difference if we upgrade the OS to Tru64 5.1a instead of 5.1?
Thanks in advance,
Alan Holsted
Metro, Portland, OR.
null

A question along the same lines, does Oracle 7.3.4 run On Tru64 Unix 5.1?
We plan to upgrade the OS and Oracle in two steps.
1. Firstly - upgrade the operating system from Tru64 4.0F to Tru64 5.1 (via 5.0A).
2. Secondly - upgrade Oracle from 7.3.4 to 8.1.7 or perhaps 9.x
Questions:
1. Will Oracle 7.3.4 run successfully on Tru64 5.1 during the transition period?
2. Does it make any difference if we upgrade the OS to Tru64 5.1A instead of 5.1?
TIA
Chris

Query Performance Problem!! Oracle 25 minutes || SQLServer 3 minutes

Hi all,
I'm having a performance problem with this query bellow. It runs in 3 minutes on SQLServer and 25 minutes in Oracle.
SELECT
CASE WHEN (GROUPING(a.estado) = 1) THEN 'TOTAL'
ELSE ISNULL(a.estado, 'UNKNOWN')
END AS estado,
CASE WHEN (GROUPING(m.id_plano) = 1) THEN 'GERAL'
ELSE ISNULL(m.id_plano, 'UNKNOWN')
END AS id_plano,
sum(m.valor_2s_parcelas) valor_2s_parcelas,
convert(decimal(15,2),convert(int,sum(convert(int,(m.valor_2s_parcelas+.0000000001)*100)*
isnull(e.percentual,0.0))/100.0+.0000000001))/100 BB_Educar
FROM
movimento_dco m ,
evento_plano e,
agencia_tb a
WHERE
m.id_plano = e.id_plano
AND m.agencia *= a.prefixo
--AND m.id_plano LIKE 'pm60%'
AND m.data_pagamento >= '20070501'
AND m.data_pagamento <= '20070531'
AND m.codigo_retorno = '00'
AND m.id_parcela > 1
AND m.valor_2s_parcelas > 0.
AND e.id_evento = 'BB-Educar'
AND a.banco_id = '001'
AND a.ordem = '00'
group by m.id_plano, a.estado WITH ROLLUP
order by a.estado, m.id_plano DESC
Can anyone help me with this query?

What version of Oracle, what version of SQL? Are the tables the same exact size? are they both indexed the same? Are you running on the some or similar hardware? Are the Oracle parameters similar like SGA size and PGA_AGGREGATE Target? Did you run statistics in Oracle?
Did you compare execution plans in SQL Server vs Oracle to see if SQl Servers execution plan is more superior than the one Oracle is trying to use? (most likely stale statistics).
There are many variables and we need more information than just the Query : ).

Performance problem between Oracle.DataAccess v1 and v2

Hi, I have serious performance problem with OracleDataReader when I use the GetValues method.
My server is Oracle 9.2.0.7, and i use ODAC v10.2.0.221
I create a dummy table for benchmark :
create table test (a varchar2(50), b number)
begin
for i in 1..62359 loop
insert into test values ('Values ' || i, i);
end loop;
commit;
end;
I use the same code for benchmark Framework v1 and Framework v2.
Code :
try {
OracleConnection c = new OracleConnection("user id=saturne_dbo;password=***;data source=satedfx;");
c.Open();
go(c);
c.Close();
catch (Exception ex) {
MessageBox.Show(ex.Message);
private void go(IDbConnection c) {
IDbCommand cmd = c.CreateCommand();
cmd.CommandText = "select * from test";
cmd.CommandType = CommandType.Text;
DateTime dt = DateTime.Now;
IDataReader reader = cmd.ExecuteReader();
int count = 0;
while (reader.Read()) {
object[] fields = new object[reader.FieldCount];
reader.GetValues(fields);
count++;
reader.Close();
TimeSpan eps = DateTime.Now - dt;
MessageBox.Show("Time " + count + " : " + eps.TotalSeconds);
Result are :
Framework v1 with OracleDataAccess 1.10.2.2.20 "Time 62359 : 0.5"
Framework v2 with OracleDataAccess 2.10.2.2.20 "Time 62359 : 3.57" FACTOR 6 !!!!!
I notice same problem with oleDb provider and Microsoft Oracle Client provider..
It's a serious problem for my production server, the time calculation explode...
Where is the explication ?
Do u know solution ?

Can you please try out following -
1. Create a .NET 1.x DLL with your benchmark code. This will obviously use ODP.NET for .NET 1.x.
2. Call this assembly routine from a .NET 1.x executable and note the results.
3. Now call this assembly routine from a .NET 2.0 executable and note the results.
The idea is to always use "ODP.NET for .NET 1.x" even in .NET 2.0 runtime. This will tell us whether the performance degradation is a runtime issue.

Question for ORACLE EXPERTS!!! PERFORMANCE PROBLEM!!!

I have 2 nodes on RAC. On node1 the following query run in 15 seconds and on node2 the same query run in 40 minutes. This is a big problem because we are migrating a SQL Server database to Oracle RAC 10gR2 (10.2.0.2) on HP-UX Itanium and we can´t finish the project because of this performance problem!!! PLEASE HELP ME ORACLE GURUS !!! I have opened a TAR at Metalink a 3 month ago,but they can´t help me with this. Can anyone explain this event to me please??? " gc cr multi block request 92011 0.33 737.49
This is the query that i run on both nodes and this is the tkprof of the trace file when i run this on second node:
select /*+ NO_PARALLEL(t) */ sum(t.saldo_em_real)
from
brcapdb2.titulo t
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 13.76 790.26 0 107219 0 0
total 3 13.76 790.26 0 107219 0 0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 31
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 0.02 0.02
gc cr multi block request 92011 0.33 737.49
gc current grant busy 1 0.00 0.00
latch: KCL gc element parent latch 4 0.00 0.00
latch: object queue header operation 17 0.00 0.01
latch free 6 0.00 0.00
gc remaster 9 1.94 9.00
gcs drm freeze in enter server mode 19 1.97 30.52
gc current block 2-way 10 0.61 2.72
SQL*Net break/reset to client 1 0.01 0.01
Please help me if you can!!
Tks,
Paulo.

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 0.02 0.02
gc cr multi block request 92011 0.33 737.49
gc current grant busy 1 0.00 0.00
latch: KCL gc element parent latch 4 0.00 0.00
latch: object queue header operation 17 0.00 0.01
latch free 6 0.00 0.00
gc remaster 9 1.94 9.00
gcs drm freeze in enter server mode 19 1.97 30.52
gc current block 2-way 10 0.61 2.72
SQL*Net break/reset to client 1 0.01 0.01There's lots of global cache traffic going on. All those multiblock transfers seem to be saturating the interconnect. Some things to consider:
- Have a look at metalink note 3951017.8 for a possible fix
- Check that your interconnect is properly configured
- Try running the query with PARALLEL hint. This would mean doing disk I/O instead of buffer & interconnect I/O.
edit: changed "without NOPARALLEL" to "with PARALLEL"
Message was edited by:
antti.koskinen

Performance Problem between Oracle 9i to Oracle 10g using Crystal XI

We have a Crystal XI Report using ODBC Drivers, 14 tables, and one sub report. If we execute the report on an Oracle 9i database the report will complete in about 12 seconds. If we execute the report on an Oracle 10g database the report will complete in about 35 seconds.
Our technical Setup:
Application server: Windows Server 2003, Running Crystal XI SP2 Runtime dlls with Oracle Client 10.01.00.02, .Net Framework 1.1, C# for Crystal Integration, Unmanaged C++ for app server environment calling into C# through a dynamically loaded mixed-mode C++ DLL.
Database server is Oracle 10g
What we have concluded:
Reducing the number of tables to 1 will reduce the execution time of the report from 180s to 13s. With 1 table and the sub report we would get 30 seconds
We have done some database tracing and see that Crystal Reports Issues the following query when verifying the database and it takes longer in 10g vs 9i.
We have done some profiling in the application code. When we retarget the first table to the target database, it takes 20-30 times longer in 10g than in 9i. Retargeting the other tables takes about twice as long. The export to a PDF file takes about 4-5 times as long in 10g as in 9i.
Oracle 10g no longer supports the /*+ RULE */ hint.
Verify DB Query:
select /*+ RULE */ *
from
(select /*+ RULE */ null table_qualifier, o1.owner table_owner,
o1.object_name table_name, decode(o1.owner,'SYS', decode(o1.object_type,
'TABLE','SYSTEM TABLE','VIEW', 'SYSTEM VIEW', o1.object_type), 'SYSTEM',
decode(o1.object_type,'TABLE','SYSTEM TABLE','VIEW', 'SYSTEM VIEW',
o1.object_type), o1.object_type) table_type, null remarks from all_objects
o1 where o1.object_type in ('TABLE', 'VIEW') union select /*+ RULE */ null
table_qualifier, s.owner table_owner, s.synonym_name table_name, 'SYNONYM'
table_type, null remarks from all_objects o3, all_synonyms s where
o3.object_type in ('TABLE','VIEW') and s.table_owner= o3.owner and
s.table_name = o3.object_name union select /*+ RULE */ null table_qualifier,
s1.owner table_owner, s1.synonym_name table_name, 'SYNONYM' table_type,
null remarks from all_synonyms s1 where s1.db_link is not null ) tables
WHERE 1=1 AND TABLE_NAME='QCTRL_VESSEL' AND table_owner='QLM' ORDER BY 4,2,
3
SQL From Main Report:
SELECT "QCODE_PRODUCT"."PROD_DESCR", "QCTRL_CONTACT"."CONTACT_FIRST_NM", "QCTRL_CONTACT"."CONTACT_LAST_NM", "QCTRL_MEAS_PT"."MP_NM", "QCTRL_ORG"."ORG_NM", "QCTRL_TKT"."SYS_TKT_NO", "QCTRL_TRK_BOL"."START_DT", "QCTRL_TRK_BOL"."END_DT", "QCTRL_TRK_BOL"."DESTINATION", "QCTRL_TRK_BOL"."LOAD_TEMP", "QCTRL_TRK_BOL"."LOAD_PCT", "QCTRL_TRK_BOL"."WEIGHT_OUT", "QCTRL_TRK_BOL"."WEIGHT_IN", "QCTRL_TRK_BOL"."WEIGHT_OUT_UOM_CD", "QCTRL_TRK_BOL"."WEIGHT_IN_UOM_CD", "QCTRL_TRK_BOL"."VAPOR_PRES", "QCTRL_TRK_BOL"."SPECIFIC_GRAV", "QCTRL_TRK_BOL"."PMO_NO", "QCTRL_TRK_BOL"."ODORIZED_VOL", "QARCH_SEC_USER"."SEC_USER_NM", "QCTRL_TKT"."DEM_CTR_NO", "QCTRL_BA_ENTITY"."BA_NM1", "QCTRL_BA_ENTITY_VW"."BA_NM1", "QCTRL_BA_ENTITY"."BA_ID", "QCTRL_TRK_BOL"."VOLUME", "QCTRL_TRK_BOL"."UOM_CD", "QXREF_BOL_PROD"."MOVEMENT_TYPE_CD", "QXREF_BOL_PROD"."BOL_DESCR", "QCTRL_TKT"."VOL", "QCTRL_TKT"."UOM_CD", "QCTRL_PMO"."LINE_UP_BEFORE", "QCTRL_PMO"."LINE_UP_AFTER", "QCODE_UOM"."UOM_DESCR", "QCTRL_ORG_VW"."ORG_NM"
FROM (((((((((((("QLM"."QCTRL_TRK_BOL" "QCTRL_TRK_BOL" INNER JOIN "QLM"."QCTRL_PMO" "QCTRL_PMO" ON "QCTRL_TRK_BOL"."PMO_NO"="QCTRL_PMO"."PMO_NO") INNER JOIN "QLM"."QCTRL_MEAS_PT" "QCTRL_MEAS_PT" ON "QCTRL_TRK_BOL"."SUP_MP_ID"="QCTRL_MEAS_PT"."MP_ID") INNER JOIN "QLM"."QCTRL_TKT" "QCTRL_TKT" ON "QCTRL_TRK_BOL"."PMO_NO"="QCTRL_TKT"."PMO_NO") INNER JOIN "QLM"."QCTRL_CONTACT" "QCTRL_CONTACT" ON "QCTRL_TRK_BOL"."DRIVER_CONTACT_ID"="QCTRL_CONTACT"."CONTACT_ID") INNER JOIN "QFC_QLM"."QARCH_SEC_USER" "QARCH_SEC_USER" ON "QCTRL_TRK_BOL"."USER_ID"="QARCH_SEC_USER"."SEC_USER_ID") LEFT OUTER JOIN "QLM"."QCODE_UOM" "QCODE_UOM" ON "QCTRL_TRK_BOL"."ODORIZED_VOL_UOM_CD"="QCODE_UOM"."UOM_CD") INNER JOIN "QLM"."QCTRL_ORG_VW" "QCTRL_ORG_VW" ON "QCTRL_MEAS_PT"."ORG_ID"="QCTRL_ORG_VW"."ORG_ID") INNER JOIN "QLM"."QCTRL_BA_ENTITY" "QCTRL_BA_ENTITY" ON "QCTRL_TKT"."DEM_BA_ID"="QCTRL_BA_ENTITY"."BA_ID") INNER JOIN "QLM"."QCTRL_CTR_HDR" "QCTRL_CTR_HDR" ON "QCTRL_PMO"."DEM_CTR_NO"="QCTRL_CTR_HDR"."CTR_NO") INNER JOIN "QLM"."QCODE_PRODUCT" "QCODE_PRODUCT" ON "QCTRL_PMO"."PROD_CD"="QCODE_PRODUCT"."PROD_CD") INNER JOIN "QLM"."QCTRL_BA_ENTITY_VW" "QCTRL_BA_ENTITY_VW" ON "QCTRL_PMO"."VESSEL_BA_ID"="QCTRL_BA_ENTITY_VW"."BA_ID") LEFT OUTER JOIN "QLM"."QXREF_BOL_PROD" "QXREF_BOL_PROD" ON "QCTRL_PMO"."PROD_CD"="QXREF_BOL_PROD"."PURITY_PROD_CD") INNER JOIN "QLM"."QCTRL_ORG" "QCTRL_ORG" ON "QCTRL_CTR_HDR"."BUSINESS_UNIT_ORG_ID"="QCTRL_ORG"."ORG_ID"
WHERE "QCTRL_TRK_BOL"."PMO_NO"=12345 AND "QXREF_BOL_PROD"."MOVEMENT_TYPE_CD"='TRK'
SQL From Sub Report:
SELECT "QXREF_BOL_VESSEL"."PMO_NO", "QXREF_BOL_VESSEL"."VESSEL_NO"
FROM "QLM"."QXREF_BOL_VESSEL" "QXREF_BOL_VESSEL"
WHERE "QXREF_BOL_VESSEL"."PMO_NO"=12345
Does anyone have any suggestions on how we can improve the report performance with 10g?

Hi Eric,
Thanks for your response. The optimizer mode in our 9i database is CHOOSE. We changed the optimizer mode from ALL_ROWS to CHOOSE in 10g but it didn't make a difference.
While researching Metalink I came across a couple of documents that indicated performance problems and issues with using certain data-dictionary views in 10g. Apparently, the definition of ALL_OBJECTS, ALL_ARGUMENTS and ALL_SYNONYMS have changed in 10g, resulting in degradation in performance, if quieried against these views. These are the same queries that crystal reports is queriying. We'll try the workaround suggested in these documents and see if it resolves the issue.
Here are the Doc Ids, if you are interested:
Note 377037.1
Note:364822.1
Thanks again for your response.
Venu Boddu.

Erratic performance problems in Oracle 8.0.x

Hi all,
We are having a performance problem that appeared somewhere between 8.0.6 and 8.1.5 when using embedded SQL and the ProC compiler under Linux and Solaris.
The moment we use client libraries > 8.0.x, things seem to grind to a halt. We are currently using 8.0.6 client against 8, 9 and 10g databases. Using 8.1.5 or 10g clients against Oracle 9 or 10 databases triggers the problem.
The problem also isn't tied to any specific query. On the latest run we tried, the timings for a specific problem query are as follows: Oracle 10 server, Oracle 8.0.6 client - 40 seconds; Oracle 10 server (same database), Oracle 10 client - 14 hours
Explain plan doesn't show anything funny with the query. On occasion, the query does get through quickly. Subsequent runs are then also quick.
The query also runs fine in SQLPlus.
What we have noticed is that the server process flatlines it at 100% CPU usage for the entire duration. The client, on the other hand is just sleeping, waiting for data from the server. Stopping the client in the debugger shows that the client is waiting in the sqlcxt() call when opening the cursor, not actually fetching data.
We are at our wits end as to where look next, and we can't stay on 8.0.6 client libraries for ever as this is starting to cause us other hassles now.
Did something significant perhaps change between 8.0.x and 8.1.x that we need to cater for in our apps?
Any help/ideas would be greatly appreciated.
Regards,
Gerhard

Check Metalink
Client / Server / Interoperability Support Between Different Oracle Versions
Doc ID: Note:207303.1
Looks like Client version 8.1.5 has some problem, it was never designed to support Oracle version higher than 8.1.7
On the other hand, 8.0.6 was supported up to 9.2
I would stay with 8.0.6 if I have to use Oracle 8 client. Client version 8.1.7 seems much better.

Oracle 10G performance problems

Hello,
we have a lot of performance problems with oracle 10G. Especially tables scan on DRAW or AEN1 have long response times. It seems that the CBO uses the wrong strategy. The latest merge fix is already installed. Any idea to solve the problem is welcome.
Best regards
Juergen Remmert

We had similar performance issues in our environment, once we upgraded from 9.2.0.2 to 10.2.0.2.
Oracle: 10.2.0.2
SAP: 4.7x110
OS: SOLARIS 9 64bit
The above mentioned notes were very helpful. We had to install an oracle patch as well (found on marketplace) -- 6321245
and make the following oracle parameters changes:
pga_aggregate_target - 144MB (default = 25MB)
*.event="10027 trace name context forever, level 1"
*.event="10028 trace name context forever, level 1"
*.event="10162 trace name context forever, level 1"
*.event="10183 trace name context forever, level 1"
*.event="10191 trace name context forever, level 1"
*.event="10629 trace name context forever, level 32"
*.event="38068 trace name context forever, level 100"
*.event="38043 trace name context forever, level 1"
*.optimizer_index_caching=50
*.optimizer_index_cost_adj=20
*.parallel_execution_message_size=16384
*._b_tree_bitmap_plans=FALSE
*._index_join_enabled=FALSE
*._optim_peek_user_binds=FALSE
*._optimizer_mjc_enabled=FALSE
*._sort_elimination_cost_ratio=10
Remove
*.optimizer_features_enable='9.2.0'
HTH

Oracle Performance problem in Tru64 Unix

Similar Messages

Maybe you are looking for