Cursor_Sharing parameter

Hi All,
On one of our db the CURSOR_SHARING parameter is set to SIMILAR (non default value) coz I think the developers are not using the Bind variables in their queries, so literals will be replaced with bind variables as this parameter is set.
I remember this parameter can also be set to FORCE to do the same. So what is the exact difference between these two.
Please clarify me on the same.
Thanks in Advanced
- Bhupinder

When using FORCE, the literals are exchanged with bind variables whenever the meaning (sematnics) of the SQL will not be changed by the bind variables.
When using SIMILAR, literals will be replaced by bind variables whenever the meaning and the optimizer plan will not be chnaged by the bind variables.
So this means that when using FORCE, by using the bind variable the optimzier plan can be changed for example:
select * from big_table where id = 12345
if there is a index on the column ID and the percent of rows having ID = 12345 is small index will be used (the table is analyzed).
but if Oracle replaces 12345 by :b1 the optimzier will not know what is the percebnt od rows with that ID until run time, sothe execution plan might be changed and full table scan can be done. If using cursor_sharing = SIMILAR Oracle in this case will not change the literal with bind variable.
Gorjan Todorovski
Oracle DBA
MOBIMAK

Similar Messages

To solve ORA-1008,set cursor_sharing parameter to EXACT

Per Bug 7154579 customer, to solve ORA-1008,set cursor_sharing parameter to EXACT but still see the error on the application.
One of the instance in our 4 node RAC USED to have cursor_sharing=similar, and the rest set to exact. Customer changed it to 'exact' longtime back. but still found some background process using cursor_sharing=similar ( and still see the error 1008) .
After the bounce of the above-mentioned node, but absent a clean restart of the whole RAC database, the customer still experienced the 1008 error. Session level is showing,INSTEAD OF "SIMILAR" for the background processes,the entries of "uninitialized". See query below:
SYS@ptmpnew4 >select inst_id,id,name,value from gV$SYS_OPTIMIZER_ENV where name like 'cursor%' ;
INST_ID ID NAME VALUE
4 48 cursor_sharing exact
3 48 cursor_sharing exact
2 48 cursor_sharing exact
1 48 cursor_sharing exact
SYS@ptmpnew4 >
SYS@ptmpnew4 >select inst_id,name,value,count(1) from gV$ses_OPTIMIZER_ENV where name like 'cursor%'
group by inst_id,name,value; 2
INST_ID NAME VALUE COUNT(1)
1 cursor_sharing exact 599
1 cursor_sharing uninit 20
2 cursor_sharing exact 590
2 cursor_sharing uninit 18
3 cursor_sharing exact 583
3 cursor_sharing uninit 19
4 cursor_sharing exact 600
4 cursor_sharing uninit 18
what could be the possible reason

cursor_sharing parameter in the init. ora allows you to change the shared pool's default behaviour when parsing and caching SQL statements.
force - allows two SQL statements, which differ only by a literal value, to share parsed code cached in the shared pool. the difference in literal values must not change the meaning of the statement.
similar - allows two sql statements, which differ only by a literal value, to share parsed code cached in the shared pool. the difference in literal values must not change the meaning of the statement or its cached execution plan.
exact - two sql statements must match exactly in order to share the parse code cached in shared pool.
refer the link given below , you will get answer for all your questions.
http://www.oracle.com/technology/oramag/oracle/06-jan/o16asktom.html
to know Parsing in Oracle, refer.
http://www.databasejournal.com/features/oracle/article.php/3341851/Parsing-in-Oracle.htm
Edited by: rajeysh on Jun 19, 2010 12:40 PM

Alternative to cursor_sharing parameter

Hello,
We presently have a 3rd party application that has an Oracle 9.2.0.8 db with statistics run on it and would like to improve performance with some bind variable queries in setting the cursor_sharing = force.
The problem is that when certain queries return a larger character set string, the apps does not accept and errors out.
Does anyone have any experience with this parameter and it's alternatives?
Much appreciated.
JR

Hi JR,
would like to improve performance with some bind variable queries in Cursor_sharing is a Godsend for shops with vendor SQL that cannot be changed, and for shops with ad-hoc query where literals appear in the SQL.
Does anyone have any experience with this parameter and it's alternatives?Before cursor_sharing, we made the shared_pool very tiny.
Since there was no reason to cached non-reentrant SQL, why even have a shared pool?
Obviously, the best remedy is to re-write your code to use host variables, but that's rarely a practical solution!
Also note that cursor_sharing=similar now works in 11g . . .
I have some notes here that you may find helpdul:
http://www.dba-oracle.com/t_cursor_sharing.htm
Hope this helps . . .
Donald K. Burleson
Oracle Press author
Author of "Oracle Tuning: The Definitive Reference"
http://www.rampant-books.com/book_2005_1_awr_proactive_tuning.htm

Cursor_sharing parameter in Force or Similar

Hi ALL,
OS:AIX
DB:11gR2
We are facing performance issues in one of our database and after investigation ADDM is suggesting that there is a lot of Hard parsing happening at the datbase level and there is a undersized SGA, We have taken care of the Shared Pool size but we for Cursor_sharing we are in a predicament. Currently it is being set to similar and earlier it was set to force but still no affect of these paremeter. These settings were suggested by Oracle Support Team.
I have also read that from 11gr2, cursor_sharing=similar has deprecated but still Oracle team sugested this setting. I more inclined to setting it to Force but I am not sure as I have also read that FORCE should be avoided as this affects the execution plan and hence similar is a more recommede method. I need to know how does it affects the execution plan per say.
Regards,
Sphinx

For this type of query, http://asktom.oracle.com has always been an excellent resource.
Here is your link
Ask Tom &quot;cursor sharing exact VS force in 11g&quot;
I recommend you always try to use it.
Sybrand Bakker
Senior Oracle DBA

CURSOR_SHARING universe parameter

Does anyone know if the CURSOR_SHARING parameter is supported in a universe (BOXI R2 SP3, FP3.3)? BOXI R2 is running on AIX, and the reporting and CMS databases are on Oracle 10g. On the database side, CURSOR_SHARING is set to FORCE. On the universe side, we want to set the CURSOR_SHARING value to EXACT. Is this possible?

The solution to this is to add the following value to the ConnectInit parameter in the Universe Connection, "alter session set cursor_sharing=exact". Don't use the double quotes in your value.

How to check query is getting reused after changing parametr cursor_sharing

Hello,
Oracle Version: 11g
OS Version: Windows 2003 64Bit
How to find if a particular query is getting reused after change in a cursor_sharing parameter from EXACT to SIMILAR.
Which set of Views/DD's should i query go get the relevant details.
Thanks in advance.
-Vijay.

SQL> desc v$sqlarea
Name                                                  Null?    Type
SQL_TEXT                                                       VARCHAR2(1000)
SQL_FULLTEXT                                                   CLOB
SQL_ID                                                         VARCHAR2(13)
SHARABLE_MEM                                                   NUMBER
PERSISTENT_MEM                                                 NUMBER
RUNTIME_MEM                                                    NUMBER
SORTS                                                          NUMBER
VERSION_COUNT                                                  NUMBER
LOADED_VERSIONS                                                NUMBER
OPEN_VERSIONS                                                  NUMBER
USERS_OPENING                                                  NUMBER
FETCHES                                                        NUMBER
EXECUTIONS                                                     NUMBER
PX_SERVERS_EXECUTIONS                                          NUMBER
END_OF_FETCH_COUNT                                             NUMBER
USERS_EXECUTING                                                NUMBER
LOADS                                                          NUMBER
FIRST_LOAD_TIME                                                VARCHAR2(19)
INVALIDATIONS                                                  NUMBER
PARSE_CALLS                                                    NUMBER
DISK_READS                                                     NUMBER
DIRECT_WRITES                                                  NUMBER
BUFFER_GETS                                                    NUMBER
APPLICATION_WAIT_TIME                                          NUMBER
CONCURRENCY_WAIT_TIME                                          NUMBER
CLUSTER_WAIT_TIME                                              NUMBER
USER_IO_WAIT_TIME                                              NUMBER
PLSQL_EXEC_TIME                                                NUMBER
JAVA_EXEC_TIME                                                 NUMBER
ROWS_PROCESSED                                                 NUMBER
COMMAND_TYPE                                                   NUMBER
OPTIMIZER_MODE                                                 VARCHAR2(10)
OPTIMIZER_COST                                                 NUMBER
OPTIMIZER_ENV                                                  RAW(797)
OPTIMIZER_ENV_HASH_VALUE                                       NUMBER
PARSING_USER_ID                                                NUMBER
PARSING_SCHEMA_ID                                              NUMBER
PARSING_SCHEMA_NAME                                            VARCHAR2(30)
KEPT_VERSIONS                                                  NUMBER
ADDRESS                                                        RAW(4)
HASH_VALUE                                                     NUMBER
OLD_HASH_VALUE                                                 NUMBER
PLAN_HASH_VALUE                                                NUMBER
MODULE                                                         VARCHAR2(64)
MODULE_HASH                                                    NUMBER
ACTION                                                         VARCHAR2(64)
ACTION_HASH                                                    NUMBER
SERIALIZABLE_ABORTS                                            NUMBER
OUTLINE_CATEGORY                                               VARCHAR2(64)
CPU_TIME                                                       NUMBER
ELAPSED_TIME                                                   NUMBER
OUTLINE_SID                                                    VARCHAR2(40)
LAST_ACTIVE_CHILD_ADDRESS                                      RAW(4)
REMOTE                                                         VARCHAR2(1)
OBJECT_STATUS                                                  VARCHAR2(19)
LITERAL_HASH_VALUE                                             NUMBER
LAST_LOAD_TIME                                                 DATE
IS_OBSOLETE                                                    VARCHAR2(1)
CHILD_LATCH                                                    NUMBER
SQL_PROFILE                                                    VARCHAR2(64)
PROGRAM_ID                                                     NUMBER
PROGRAM_LINE#                                                  NUMBER
EXACT_MATCHING_SIGNATURE                                       NUMBER
FORCE_MATCHING_SIGNATURE                                       NUMBER
LAST_ACTIVE_TIME                                               DATE
BIND_DATA                                                      RAW(2000)

Dedicated database & cursor_sharing

I have Oracle db 11gr2 on aix wich is running in dedicated mode.
Based on a application documentation, I put cursor_sharing parameter to EXACT.
but, I wonder... could it there be any cursor sharing if a db is in dedicated mode?

PrafullaNath wrote:
Oracle says we should keep cursor_sharing=similar. Could you point out a documentation with this ?
EXACT is the default value:
http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/initparams041.htm#REFRN10025
Using any other value than the default one requires strong application testing since it has been caused a lot of troubles by the past (wrong results were returned).
Nicolas.

Cursor_sharing=similar or cursor_sharing=exact

Hai,
I have doubt regarding setting cursor_sharing parameter exact and similar at session level.
On my database cursor_sharing is set similar at system level.
test >show parameter cursor
NAME                                 TYPE                             VALUE
cursor_sharing                       string                           SIMILARI have fired a simple select statement without setting any cursor_sharing at session level
TEST >variable b1 number;
TEST >exec :b1:=7499;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
TEST >select empno,job from emp where job='SALESMAN' and empno=:b1;
     EMPNO JOB
      7499 SALESMANchecking the hash value for query fired
test >select sql_text,invalidations,hash_value,executions,loads from v$sqlarea
16:14:50   2 where sql_text like '%select empno,job from%';
SQL_TEXT
INVALIDATIONS HASH_VALUE EXECUTIONS      LOADS
select empno,job from emp where job=:"SYS_B_0" and empno=:b1
            0 3727168047          1          1Literal job='SALESMAN' is converted into system generated bind variable job=:"SYS_B_0" as my cursor_sharing=similar
Fired the same statement by setting cursor_sharing=exact at session level
TEST >alter session set cursor_sharing=exact;
Session altered.
Elapsed: 00:00:00.00
16:15:25 TEST >select empno,job from emp where job='SALESMAN' and empno=:b1;Checking the hash value for newly fired query with cursor_sharing=exact
SQL_TEXT
INVALIDATIONS HASH_VALUE EXECUTIONS      LOADS
select empno,job from emp where job='SALESMAN' and empno=:b1
            0 2065003705          1          1
select empno,job from emp where job=:"SYS_B_0" and empno=:b1
            0 3727168047          1          1literal job='SALESMAN' is not converted into bind variable as my cursor_sharing=exact
At the same session fired the same query by setting cursor_sharing=similar ..to check which hash value would be shared.
16:15:28 TEST >alter session set cursor_sharing=similar;
Session altered.
Elapsed: 00:00:04.09
17:27:54 TEST >select empno,job from emp where job='SALESMAN' and empno=:b1;
     EMPNO JOB
      7499 SALESMAN
16:28:26 test >select sql_text,invalidations,hash_value,executions,loads from v$sqlarea
17:28:13   2 where sql_text like '%select empno,job from%';
SQL_TEXT
INVALIDATIONS HASH_VALUE EXECUTIONS      LOADS
select empno,job from emp where job='SALESMAN' and empno=:b1
            0 2065003705          2          *2*
select empno,job from emp where job=:"SYS_B_0" and empno=:b1
            0 3727168047          1          1The hash value 2065003705 (cursor_sharing=exact) is shared as executions column is changed from 1 to 2.
So after setting parameter cursor_sharing = similar why the hash value of 3727168047(cursor_sharing=similar)
is not shared?I guess something is cached at session level but i want to know the exact reason..
Again i flushed the shared pool
test >alter system flush shared_pool;
System altered.
Elapsed: 00:00:03.09
17:39:40 test >select sql_text,invalidations,hash_value,executions,loads from v$sqlarea
17:39:44   2 where sql_text like '%select empno,job from%';
SQL_TEXT
INVALIDATIONS HASH_VALUE EXECUTIONS      LOADS
select empno,job from emp where job='SALESMAN' and empno=:b1
            0 2065003705          0          2The hash value of 3727168047(cursor_sharing=similar) is removed ..not hash value 2065003705
What is the reason behind that ...
Regards,
Meeran

Meeran wrote:
The hash value 2065003705 (cursor_sharing=exact) is shared as executions column is changed from 1 to 2.
So after setting parameter cursor_sharing = similar why the hash value of 3727168047(cursor_sharing=similar)
is not shared?I guess something is cached at session level but i want to know the exact reason..Because there is a query in the shared_pool with same literal value so it doesn't have to use the hash 3727168047 and substitute the bind where it already has a plan for the same statement which is 2065003705.
I think with setting CURSOR_SHARING=similar again, If you try the query with JOB='ANALYST' then it will use the plan 3727168047 and substitute the bind with 'ANALYST'.
Again i flushed the shared pool
test >alter system flush shared_pool;
System altered.
Elapsed: 00:00:03.09
17:39:40 test >select sql_text,invalidations,hash_value,executions,loads from v$sqlarea
17:39:44   2 where sql_text like '%select empno,job from%';
SQL_TEXT
INVALIDATIONS HASH_VALUE EXECUTIONS      LOADS
select empno,job from emp where job='SALESMAN' and empno=:b1
0 2065003705          0          2The hash value of 3727168047(cursor_sharing=similar) is removed ..not hash value 2065003705
What is the reason behind that ...If you have noticed, the executions for the hash plan 2065003705 are 0 after the shared_pool flushing. It seems that with flush shared_pool, oracle doesn't flush the queries with literals and just reset their stats. As literals are always the culprits.
You may also wanna read this, as good document on CURSOR_SHARING.

Index usage making SQL slower.

Hello,
While working on a performance tuning activity on Oracle 10.2.0.4 on Solaris 10, I encountered a problem wherein one of our DBA's suggested indexing 2 columns of a certain table. One of the queries which is being run on that table has a RULE hint, and it is seen to be making use of this newly created index. Before the index was created, this query was running fine and getting completed within 30 mins or so. However after the index is created, it is now taking 12 hours on average to complete. Please note that in both the above cases, the CURSOR_SHARING parameter was set to EXACT. Yes, after the index was created its statistics were computed, and for both the index and the base table statistics were gathered. The query is making use of bind variables and is being run via the SQR engine of PeopleSoft.
Please advice what can be the possible reasons for such delays being caused?
For any information, please let me know and I would provide the same in this forum/
Note for moderators: I could not find the section for Performance tuning, so I am asking this question in the general forum. Apologies.
Thank You,
Prashant.

Index scans are not always faster.
Full table scans are not always bad.
I doubt that the RULE hint is necessary.
In general, [url http://www.centrexcc.com/Tuning%20by%20Cardinality%20Feedback.pdf]the CBO does an excellent job of finding the best access plan for a given sql provided it is able to accurately estimate the cardinalities of the row sources in the plan.
See advice and information required in the template tuning threads:
[url https://forums.oracle.com/forums/thread.jspa?threadID=863295]How to post a sql tuning request
[url https://forums.oracle.com/forums/thread.jspa?messageID=1812597]When your query takes too long

Statpack analyzing of 9i database.

hi Expertise
Please help me for sorting the statpack report of my production DB in 9i. Also advise some recommendation after analyzing my statpack view.
Elapsed:     3.75 (min)     225 (sec)
DB Time:     7.84 (min)     470.65 (sec)
Cache:     10,016 MB
Block Size:     8,192 bytes
Transactions:     2.01 per second
Performance Summary
Physical Reads:     15,666/sec          MB per second:     122.39 MB/sec
Physical Writes:     22/sec          MB per second:     0.17 MB/sec
Single-block Reads:     1,412.69/sec          Avg wait:     0.03 ms
Multi-block Reads:     1,916.26/sec          Avg wait:     0.05 ms
Tablespace Reads:     3,346/sec          Writes:     22/sec
Top 5 Events
Event     Percentage of Total Timed Events
CPU time     79.89%
PX Deq: Execute Reply     6.38%
db file scattered read     4.32%
SQL*Net more data from dblink     4.29%
db file sequential read     2.00%
Tablespace I/O Stats
Tablespace     Read/s     Av Rd(ms)     Blks/Rd     Writes/s     Read%     % Total IO
TS_CCPS     3,117      0     2.5      0      100%     92.5%
TS_OTHERS     204      0.2     26.2      1      99%     6.09%
TS_AC_POSTED03     19      1.9     127      2      89%     0.63%
Load Profile
Logical reads:     42,976/s          Parses:     39.41/s
Physical reads:     15,666/s          Hard parses:     5.43/s
Physical writes:     22/s          Transactions:     2.01/s
Rollback per transaction:     0%          Buffer Nowait:     100%
4 Recommendations:
Your database has relatively high logical I/O at 42,976 reads per second. Logical Reads includes data block reads from both memory and disk. High LIO is sometimes associated with high CPU activity. CPU bottlenecks occur when the CPU run queue exceeds the number of CPUs on the database server, and this can be seen by looking at the "r" column in the vmstat UNIX/Linux utility or within the Windows performance manager. Consider tuning your application to reduce unnecessary data buffer touches (SQL Tuning or PL/SQL bulking), using faster CPUs or adding more CPUs to your system.
You are performing more than 15,666 disk reads per second. High disk latency can be caused by too-few physical disk spindles. Compare your read times across multiple datafiles to see which datafiles are slower than others. Disk read times may be improved if contention is reduced on the datafile, even though read times may be high due to the file residing on a slow disk. You should identify whether the SQL accessing the file can be tuned, as well as the underlying characteristics of the hardware devices.
Check your average disk read speed later in this report and ensure that it is under 7ms. Assuming that the SQL is optimized, the only remaining solutions are the addition of RAM for the data buffers or a switch to solid state disks. Give careful consideration these tablespaces with high read I/O: TS_CCPS, TS_OTHERS, TS_AC_POSTED03, TS_RATING, TS_GP.
You have more than 1,222 unique SQL statements entering your shared pool, with the resulting overhead of continuous RAM allocation and freeing within the shared pool. A hard parse is expensive because each incoming SQL statement must be re-loaded into the shared pool; with the associated overhead involved in shared pool RAM allocation and memory management. Once loaded, the SQL must then be completely re-checked for syntax & semantics and an executable generated. Excessive hard parsing can occur when your shared_pool_size is too small (and reentrant SQL is paged out) or when you have non-reusable SQL statements without host variables. See the cursor_sharing parameter for an easy way to make SQL reentrant and remember that you should always use host variables in you SQL so that they can be reentrant.
Instance Efficiency
Buffer Hit:     69.13%          In-memory Sort:     100%
Library Hit:     96.4%          Latch Hit:     99.99%
Memory Usage:     95.04%          Memory for SQL:     64.19%
2 Recommendations:
Your Buffer Hit ratio is 69.13%. The buffer hit ratio measures the probability that a data block will be in the buffer cache upon a re-read of the data block. If your database has a large number of frequently referenced table rows (a large working set), then investigate increasing your db_cache_size. For specific recommendations, see the output from the data buffer cache advisory utility (using the v$db_cache_advice utility). Also, a low buffer hit ratio is normal for applications that do not frequently re-read the same data blocks. Moving to SSD will alleviate the need for a large data buffer cache.
Your shared pool maybe filled with non-reusable SQL with 95.04% memory usage. The Oracle shared poolcontains Oracle´s library cache, which is responsible for collecting, parsing, interpreting, and executing all of the SQL statements that go against the Oracle database. You can check the dba_hist_librarycache table in Oracle10g to see your historical library cache RAM usage.
SQL Statistics
Click here to see all SQL data
Wait Events
Event     Waits     Wait Time (s)     Avg Wait (ms)     Waits/txn
PX Deq: Execute Reply     137     30     219     0.3
db file scattered read     431,159     20     0     951.8
SQL*Net more data from dblin     51,140     20     0     112.9
db file sequential read     317,856     9     0     701.7
io done     6,842     5     1     15.1
db file parallel read     21     1     52     0.0
local write wait     250     1     4     0.6
db file parallel write     825     1     1     1.8
SQL*Net message from dblink     208     1     3     0.5
log file parallel write     2,854     1     0     6.3
0 Recommendations:
Instance Activity Stats
Statistic     Total     per Second     per Trans
SQL*Net roundtrips to/from client     87,889     390.6     194.0
consistent gets     10,141,287     45,072.4     22,387.0
consistent gets - examination     884,579     3,931.5     1,952.7
db block changes     100,342     446.0     221.5
execute count     18,913     84.1     41.8
parse count (hard)     1,222     5.4     2.7
parse count (total)     8,868     39.4     19.6
physical reads     3,525,003     15,666.7     7,781.5
physical reads direct     539,879     2,399.5     1,191.8
physical writes     5,132     22.8     11.3
physical writes direct     29     0.1     0.1
redo writes     1,598     7.1     3.5
session cursor cache hits     4,378     19.5     9.7
sorts (disk)     0     0.0     0.0
sorts (memory)     4,988     22.2     11.0
table fetch continued row     310     1.4     0.7
table scans (long tables)     82     0.4     0.2
table scans (short tables)     18,369     81.6     40.6
workarea executions - onepass     0     0.0     0.0
5 Recommendations:
You have high network activity with 390.6 SQL*Net roundtrips to/from client per second, which is a high amount of traffic. Review your application to reduce the number of calls to Oracle by encapsulating data requests into larger pieces (i.e. make a single SQL request to populate all online screen items). In addition, check your application to see if it might benefit from bulk collection by using PL/SQL "forall" or "bulk collect" operators.
You have 3,931.5 consistent gets examination per second. "Consistent gets - examination" is different than regular consistent gets. It is used to read undo blocks for consistent read purposes, but also for the first part of an index read and hash cluster I/O. To reduce logical I/O, you may consider moving your indexes to a large blocksize tablespace. Because index splitting and spawning are controlled at the block level, a larger blocksize will result in a flatter index tree structure.
You have high update activity with 446.0 db block changes per second. The DB block changes are a rough indication of total database work. This statistic indicates (on a per-transaction level) the rate at which buffers are being dirtied and you may want to optimize your database writer (DBWR) process. You can determine which sessions and SQL statements have the highest db block changes by querying the v$session and v$sessatst views.
You have high disk reads with 15,666.7 per second. Reduce disk reads by increasing your data buffer size or speed up your disk read speed by moving to SSD storage. You can monitor your physical disk reads by hour of the day using AWR to see when the database has the highest disk activity.
You have high small table full-table scans, at 81.6 per second. Verify that your KEEP pool is sized properly to cache frequently referenced tables and indexes. Moving frequently-referenced tables and indexes to SSD or theWriteAccelerator will significantly increase the speed of small-table full-table scans.
Buffer Pool Advisory
Current:     3,599,469,418 disk reads
Optimized:     1,207,668,233 disk reads
Improvement:     66.45% fewer
The Oracle buffer cache advisory utility indicates 3,599,469,418 disk reads during the sample interval. Oracle estimates that doubling the data buffer size (by increasing db_cache_size) will reduce disk reads to 1,207,668,233, a 66.45% decrease.
Init.ora Parameters
Parameter     Value
cursor_sharing     similar
db_block_size     8,192
db_cache_size     8GB
db_file_multiblock_read_count     32
db_keep_cache_size     1GB
hash_join_enabled     true
log_archive_start     true
optimizer_index_caching     90
optimizer_index_cost_adj     25
parallel_automatic_tuning     false
pga_aggregate_target     2GB
query_rewrite_enabled     true
session_cached_cursors     300
shared_pool_size     2.5GB
optimizercost_model     choose
1 Recommendations:
You are not using large blocksizes for your index tablespaces. Oracle research proves that indexes will build flatter tree structures in larger blocksizes.

Systemwide Tuning using STATSPACK Reports [ID 228913.1] and http://jonathanlewis.wordpress.com/statspack-examples/ should be useful.

Please reply:how to avoid extra trailing spaces while using cursor sharing

i am using cursor sharing with FORCE or SIMILAR.
what is the solution to avoid extra trailing spaces without any java code change.
do we have any option in oracle to avoid extra trailing spaces during the query processing ?
I am using Oracle 10g
CURSOR SHARING is a feature in which multiple sql statements
which are same will have a shared cursor (in the library cache) for an oracle session,
i.e, the first three steps of the sql processing (hard parse, soft parse, optimization)
will be done only the first time that kind of statement is executed.
There are two ways in which similar SQL statements with different condition values can be made to "SHARE" cursor during execution:
1. Writing SQLs with Bind Variables: SQLs having no hard coded literals in them
For e.g., the query below
SELECT node.emp_name AS configid
FROM emp node
WHERE emp_no = :1
AND dept_no =
DECODE (SUBSTR (:2, 1, 3),
:3, :4,
(SELECT MAX (dept_no)
FROM emp
WHERE emp_no = :5 AND dept_no <= :6)
AND node.dept_type = :7
ORDER BY node.emp_name
Here all the variables are dynamically bound during the execution. The ":X" represents BIND Variable and the actual values are bound to the SQL only at the 4th step of the execution of the SQL.
In applications: The queries written with "?" as bind variables will be converted into ":X" and are sqls with Bind Variables.
2. The CURSOR_SHARING parameter: Only Useful for SQL statements containing literals:
For eg., the query below:
SELECT node.emp_name AS configid
FROM emp node
WHERE emp_no = 'H200'
AND dept_no =
DECODE (SUBSTR (:1, 1, 3),
'PLN', :2,
(SELECT MAX (dept_no)
FROM emp
WHERE emp_no = :3 AND dept_no <= :4)
AND node.dept_type = :5
ORDER BY node.emp_name
In the query above, there are two hard coded literals H200 , PLN. In this case when the same SQL executed with different values like (H2003 , PLN), oracle will create a new cursor for this statement and all the first three steps ( hard & soft parse and optimization plan) needs to be done again.
This can be avoided by changing the CURSOR_SHARING parameter which can be set to any of three values:
1. EXACT: Causes the mechanism not be used, i.e. no cursor sharing for statements with different literals. This is the default value.
2. FORCE: Causes unconditional sharing of SQL statements that only differ in literals.
3. SIMILAR: Causes cursor sharing to take place when this is known not to have any impact on optimization.
So, FORCE and SIMILAR values of the parameter will be helping in cursor sharing and improve the performance of the SQLs having literals.
But here the problem arises if we use the FORCE and SIMILAR other than EXACT.
alter session set cursor_sharing ='EXACT'
select 1 from dual;
'1'
1
alter session set curson_sharing='FORCE'
select 2 from dual;
'2'
2
alter session set curson_sharing='SIMILAR'
select 3 from dual;
'3'
3
So, this will give extra trailing spaces in when we retrieve from java method and any
further java processing based on the hardcoded literal values will fail. this needs lot of
effort in remodifying the existing millions of lines of code.
My question is i have to use cursor sharing with FORCE or SIMILAR and can't we do the trimming
from the oracle query processing level ?
please help me on this ?
Message was edited by:
Leeladhar
Message was edited by:
Leeladhar

Please reply to this thread
How to avoid extr trailing spaces using Cursor sharing opton FORCE, SIMILAR

Custom Schedule Task error

Schedule Task Logic:
SQL query to get list of user id's
For each user get resource objects
Update UPN for AD resource if Status 'provisioned' or 'enabled'
1) After Schedule task processes 500-600 users i get following error in log for each subsequent user.
09:42:27,608 ERROR [XELLERATE.DATABASE] Class/Method: tcDataBase/readPartialStatement encounter some problems: ORA-01000: maximum open cursors exceeded
java.sql.SQLException: ORA-01000: maximum open cursors exceeded
at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
2) i do check for isStop() method and try to return from code but Schedule Task keeps running till all the users are processed.
NOTE: Number of users to be processed are 9-10K.
Thanks a lot.

Here is the solution:
1) Login to the OIM database as sys and run the query:
SQL> select name,value from v$parameter where name like '%curs%';
NAME - VALUE
cursor_space_for_time - FALSE
session_cached_cursors - 20
cursor_sharing - EXACT
open_cursors - 300
change cursor_sharing parameter to *'FORCE'* in the init.ora or spfile, and bounce the database.
2) The method should be isStopped() for checking the Stop Execution checkbox in the shceduler.
Thanks
Sunny

Open cursor

Hello All,
my question about open_cursor.the scenario is as under
1sqlplus scott/tiger
2.select * from emp; in scott schema
3.open_cursor=1
4.select * from emp; in same scott schema
5.open_cursor=1
can you tell me why open_cursor value is not increased with 2 why it is one.
Thank You All For Response in Advance.

Hi,
AFAIk, See if you remember the soft parsing is going to carry out for the same/similar sql statement is executed further depending on cursor_sharing parameter.
You can get the details from v$open_cursor view perhaps if you check from below kernel table where same cursor is getting utilized and check for column
KGLLKEXC.
select * from x$kgllk where user_name='SCOTT' and kgllkctp ='OPEN' -- just for you understanding purpose.
check for statistics you can the informaiton
select a.value, s.username, s.sid, s.serial#,a.statistic#,b.name
from v$sesstat a, v$statname b, v$session s
where a.statistic# = b.statistic# and s.sid=a.sid
and s.username='SCOTT'
and b.statistic# in (3,4,10,498,499,524)
- Pavan Kumar N

Parameters to be considered for tuning the QUERY Performance.

Hi Guys
I wanted to identify the Query which is taking more resources through the Dynamic performance views and not through OEM.I wanter to tune the Query.
Please suggest me on this. Also i wanted to know what are all the parameters to be considered for tuning a query like Query execution time, I/O Hits, Library cache hits, etc and from which performance view these paramaters can be taken. I also wanted to know how to find the size of library cache and how much queries can be holded in a library cache and what will be the retention of queries in library cache and how to retrive the queries from Library cache.
Thanks a lot
Edited by: user448837 on Sep 23, 2008 9:24 PM

Hmm there is a parameter called makemyquery=super_fast, check that ;-).
Ok jokes apart, your question is like asking a doctor that when a person is sick than how to troubleshoot his sickeness? So does a doctor start giving medicine immediately? No right? He has to check some symptoms of the patient. The same is applicable to the query also. There is no view as such which would tell you the performance of the query ie it is good or bad. Tell me if a query is taking up 5 minutes and I come and tell you this, what would you say its good or bad or the query took this much CPU time what would you say, its too much or too less? I am sure your answers would be "it depends". That's the key point.
The supermost point in the performance check is two things, one the plan of the query. What kind of plan optimizer took for the query and whether it was really good or not? There are millions os ways to do som ething but the idea is to do it in the best way. That's what the idea of reading explain plan. I would suggest get your self familiar with explain plan's various paths and their pros and cons. Also about the query's charectristics, you can check V$sql, v$sqlarea , V$sql_text views.
Your other question that you want to check the size of the library cache , its contents and the retention, I would say that its all internally managed. You never size library cache but shared pool only. Similary the best bet for a dba/developer is to check the queries are mostly shareable and there wont be any duplicate sqls. So the cursor_sharing parameter can be used for this. The control is not given to us to manage the rentention or the flushing of the queries from the cache.
HTH
Aman....

Converting an old Tom Kyte function to straight SQL

I am on Oracle 10.2
There is an old tom kyte function (10+ years old) floating around that will remove constants so I can look for queries that don't use bind variables. It has to loop through each character i a sql so its slow. I was able to convert part of it to using a regular expression. There are alot of new SQL features, so I am trying to replace it with sql.
The old REMOVE_CONSTRAINTS function is at the bottom.
I have already converted the really slow part of the function which loops through every character in a query (first loop). I did it with a regular expression. See test case below.
I am having trouble with the second part that replaces numbers.
The translate is there because I was having trouble passing a single quote to a regular expression and got tired of looking at it. So I converted all single quotes to '@''
Basically the translate turns all single quotes to @
So anything surrounded by an @ and an @ gets turned into a single @
This is a bit flawed. If I have a literal that has a quote in it, this will get screwed up. It is not something I have to worry about right now though.
select mytest,regexp_replace(translate(to_char(mytest),chr(39),'@'),'@[^@]+@','@') from test
create table test (mytest clob);
insert into test values ('select 1 from mytable where x = '||chr(39)||'v'||chr(39)||' and y = '||chr(39)||'q'||chr(39));
insert into test values ('select 1 from mytabe where a = '||chr(39)||'xyz'||chr(39));
commit;
SQLt> select mytest,regexp_replace(translate(mytest,chr(39),'@'),'@[^@]+@','@') from test
2 /
MYTEST
REGEXP_REPLACE(TRANSLATE(MYTEST,CHR(39),'@'),'@[^@]+@','@')
select 1 from mytable where x = 'v' and y = 'q'
select 1 from mytable where x = @ and y = @
select 1 from mytabe where a = 'xyz'
select 1 from mytabe where a = @I can put this in a pipeline function and it will run fast enough. I think I can probably make this straight sql. anyone know how? also, I have some column names with numbers in it. anyone know a good way to ignore numbers on the left side of the where clause?
    l_query := translate( l_query, '0123456789', '@@@@@@@@@@' );
--   dbms_output.put_line(l_query);
    for i in 0 .. 8 loop
        l_query := replace( l_query, lpad('@',10-i,'@'), '@' );
        l_query := replace( l_query, lpad(' ',10-i,' '), ' ' );
    end loop;
function remove_constraints ( p_query in clob ) return clob AS
    l_query clob;
    l_char varchar2(1);
    l_in_quotes boolean default FALSE;
    l_length number := 0;
    vmodule varchar2(30);
    vaction varchar2(30);
begin
    dbms_application_info.read_module(vaction,vmodule);
    dbms_application_info.set_module(vaction,nvl(vmodule,0)+1);
    for i in 1 .. length( p_query )
    loop
        l_char := substr(p_query,i,1);
        if ( l_char = '''' and l_in_quotes )
        then
            l_in_quotes := FALSE;
        elsif ( l_char = '''' and NOT l_in_quotes )
        then
            l_in_quotes := TRUE;
            l_query := l_query || '''#';
            dbms_output.put_line('a '||l_char);
            dbms_output.put_line( '''#');
        end if;
        if ( NOT l_in_quotes ) then
            l_query := l_query || l_char;
        end if;
    end loop;
--dbms_output.put_line(l_query);
    l_query := translate( l_query, '0123456789', '@@@@@@@@@@' );
--   dbms_output.put_line(l_query);
    for i in 0 .. 8 loop
        l_query := replace( l_query, lpad('@',10-i,'@'), '@' );
        l_query := replace( l_query, lpad(' ',10-i,' '), ' ' );
    end loop;
    return upper(l_query);
end;


In 10g you can use
FORCE_MATCHING_SIGNATURE     The signature used when the CURSOR_SHARING parameter is set to FORCE
http://docs.oracle.com/cd/B19306_01/server.102/b14237/dynviews_2113.htm#REFRN30246

Cursor_Sharing parameter

Similar Messages

Maybe you are looking for