All Rows

select cache/tot*100 "Session cursor cache%"
from
(select value tot from v$sysstat where name='parse count (total)'),
( select value cache from sys.v_$sysstat where name = 'session cursor cache hits
' );
select max(value) from v$sesstat where STATISTIC# in (select STATISTIC# from v$s
tatname where name='session cursor cache count');
****
alter system set session_cached_cursors=200 scope=spfile sid ='*'
system restart required.

***
alter system set parallel_automatic_tuning = true scope=SPFILE sid='*';
*** its depreciated
"According to Oracle, this parameter is deprecated in 10G as the default values
for parallel configuration parameters are optimal. However, when I ve tried changi
ng the value, apart from generating a warning, it seems to me that the behaviour
is the same as previous versions! "
***
alter system set parallel_execution_message_size = 4096 scope=SPFILE sid='*';
*****
alter system set job_queue_processes = 65 scope=BOTH sid='*';
alter system set star_transformation_enabled = TRUE scope=BOTH sid='*';
alter system set query_rewrite_integrity = ENFORCED scope=BOTH sid='*';
alter system set parallel_threads_per_cpu = 2 scope=BOTH sid='*';
alter system set db_file_multiblock_read_count = 64 scope=BOTH sid='*';
parallel_automatic_tuning = true -- as per the oracle 10g document it is depreci
ated
parallel_execution_message_size = 4096
session_cached_cursors = 200
job_queue_process = 65
db_files = 600 not identified
star_transformation_enabled = false
Transaction = 300
shared_pool_size = 0
query_rewrite_integrity = ENFORCED
parallel_threads_per_Cpu = 2
large_pool_size = 0
db_file_multiple_read_count
sort_area_size
dispactches
Hi
>> if my query retrieve 999 rows is there no difference between all_rows and fir
st_rows1000?
Yes, they act different!
In general, first_rows favors index access (OLTP) while all_rows favors full-sca
ns (data warehouses).
http://www.dba-oracle.com/art_orafaq_oracl...ptimization.htm
Oracle Corporation states that with first_rows_n optimization, Oracle queries gi
ve the best possible response time for the first rows of a result set. Quicker r
esponse with the first N rows enhances user satisfaction in many applications, s
ince users receive their initial set of data more rapidly.
By tipping-off the Oracle Cost-base optimizer (CBO) that the query will only ret
urn a small set of rows, the CBO can use this cardinality information to determi
ne the optimal table join order for multi-table queries.
Glad that you have tracked down the problem.

You can change the setting by:
1, alter system set optimizer_mode=choose scope=both sid=*
If you are using spfiles
or
2, editing the initXXX.ora file.
Re: How to find current init.ora file

Posted: Jul 27, 2006 6:23 AM in response to: user453384 Reply
As far as I know, there's no possible way to find out which parameter file was u
sed to start instance. And, even if it was, I don't really see much sense in it
because parameter file is a client-side file, and usually it required to start u
p Oracle instance remotely.
In principle, parameter files are obsolete beasts, consider using server paramet
er file (SPFILE) instead. And, for SPFILE, it's pretty easy to find out its loca
tion:
SQL> show parameter pfile

NAME TYPE VALUE
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
-----------
spfile string %ORACLE_HOME%\DATABASE\SPFILE%
ORACLE_SID%.ORA
As for your ORA-02096 error, you have two opportunities to resolve it.
If you decided to use SPFILE, create one (for example, using CREATE SPFILE FROM
PFILE command), start your instance with SPFILE then issue:
ALTER SYSTEM SET optimizer_mode=RULE SCOPE = SPFILE;

and bounce your instance.
If you still wish to use old-style parameter file, you have to add corresponding
setting into that file manually (it's a plain text file in fact) and restart in
stance.
Regards.
Thnx Andrew & Colin,
Actually we are having siebel-crm database on oracle9.2 side and siebel best pra
ctice says to use RBO. (wrt unique index and rowid)
i have the following spfile and init.ora files in the dadabase
C:\oracle\ora92\database\SPFILEORSBL.ora
C:\oracle\admin\ORSBL\pfile\init.ora
C:\oracle\ora92\dbs\initdw.ora
To Do:-
1.While creating the spfile whether i have to take same name SPFILEORSBL.ora?
CREATE SPFILE='C:\oracle\ora92\database\SPFILEORSBL.ora'
FROM PFILE='C:\oracle\admin\ORSBL\pfile\init.ora'
after creating spfile
1.startup spfile='C:\oracle\ora92\database\SPFILEORSBL.ora'
2.ALTER SYSTEM SET optimizer_mode=RULE SCOPE = SPFILE;
3.and bounce your instance. (shutdown )
Please if verify the above steps whether it is correct or not ?
Documentation says "The SCOPE clause has the same behavior as described for the
alter_system_set_clause." when it talks about alter_system_reset_clause. But
dynamically changeable parameter cannot be reset with scope=both:
SQL> alter system set timed_statistics = false;
System altered.
SQL> alter system reset timed_statistics scope=both sid='*';
alter system reset timed_statistics scope=both sid='*'
*
ERROR at line 1:
ORA-32009: cannot reset the memory value for instance * from instance GIRL
SQL> alter system reset timed_statistics scope=spfile sid='*';

System altered.
SQL> alter system set timed_statistics = true;
System altered.
The above test restores everything to its old setting. But if you try an
underscore parameter (dynamically changeable), you'll have one difference made
to the running instance: "show parameter" will show the value after the test,
even though the value is back to the default.
It's not a big deal except Enterprise Manager will warn you about a policy
violation "Use of Non-Standard Initialization Parameters". I don't want to
suppress this warning and don't want to bounce the instance to remove this
parameter from "show parameter". Is there a workaround?
There are more than 250 documented and more than 900 documented parameters for O
racle 10g
You can query the documented parameters with the query below
select name,value,isdefault,isses_modifiable,issys_modifiable,
isinstance_modifiable,isdeprecated
from v$parameter
You can query the list of undocumented parameters with the script mentioned befo
re how to view list of hidden parameters
Also you can query v$parameter2 as the same way you query the v$parameter view t
o view the session specific parameter values.
The values from the columns isdefault,isses_modifiable,issys_modifiable,
isinstance_modifiable,isdeprecated are important.
isdefault = TRUE/FALSE indicates if the value is the default value
isses_modifiable=TRUE/FALSE indicates if the value can be modified by sessions
issys_modifiable = IMMEDIATE/DEFERRED/FALSE indicates if the value can be modifie
d by alter system command. Values represents when the changes takes effect. For
immediate, no matter what you use (spfile or init file ) parameter change takes
effect immediately.For deferred, parameter can be changed but change takes affec
t in subsequent sessions not for currently established sessions. For false it me
ans parameter cannot be changed if you dont have a spfile.
isinstance_modifiable= true/false this option is spesicif for RAC which has multi
ple instances for one database
If you want to view value of the parameter briefly you can also use show paramet
er command which searches the entered string with wildcard on both ends
SQL> show parameter pool
NAME TYPE VALUE
buffer_pool_keep string
buffer_pool_recycle string
global_context_pool_size string
java_pool_size big integer 0
large_pool_size big integer 0
olap_page_pool_size big integer 0
shared_pool_reserved_size big integer 7759462
shared_pool_size big integer 0
streams_pool_size big integer 0
As you see the output above all parameters which include pool string in it are lis
ted briefly.
Setting Parameter for Instance
You can set the parameter values with the command below
Alter system set parameter=value <comment= text > <deferred>
<scope=memory|spfile|both> <sid= sid|* >
elements of the command;
scope =BOTH/SPFILE/MEMORY indicates the scope of the parameter setting. both is
the default behaviour.
sid = SID/* if you are on RAC environment you can give SID or * for this element
which indicate that the setting will effect only the given SID or all nodes in
RAC configuration.
comment= You can comment the change for future lookups. This comment can be view
ed from UPDATE_COMMENT column of v$parameter view.
deferred = this is the interesting element which i was aware of the existence ti
ll i read the book of Mr. Kyte. Indicates that the parameter change takes place
for subsequent sessions only (not currently established sessions, including the
one making the change). This element must be used for the parameters whose ISSYS
_MODIFIABLE column in v$parameter view is deferred.
When you want to change the parameter only for the running instance and not for t
he subsequent instance you can change it only in memory. ;
SQL> alter system set cpu_count=4 scope=MEMORY;
System altered.
When you want to change the parameter for subsequent instances only
SQL> alter system set cpu_count=4 scope=SPFILE;
System altered.
When you want to change the parameter for running and subsequent instances (if is
sys_modifiable is not false);
SQL> alter system set cpu_count=4 scope=BOTH;
System altered.
!!!!!When using an init.ora parameter file, the default and only valid
value is SCOPE=MEMORY. So you must manually edit your init.ora file to change th
e parameter for subsequent instances.
Setting Parameters for sessions
You can change the values of some parameters whose ISSES_MODIFIABLE column of v$
parameter view is TRUE. Scope of the parameter will be the end of the session.
SQL> alter session set timed_statistics=false;
Session altered.
SQL> show parameter timed_statistics
NAME TYPE VALUE
-
timed_statistics boolean FALSE
Resetting/Unsetting parameters
If you want to use the default value of the parameter you have changed. You must
reset it.
alter system reset parameter <scope=memory|spfile|both> sid= sid|*
Elements are same as setting parameter. The only difference is you must give si va
lue(for single instance use * ).
SQL> alter system reset control_file_record_keep_time scope=spfile sid= *';
System altered.
!!!!!Do not try to change the value of a parameter with or null to reset it to d
efault
Common Error codes for parameter setting/resetting;
1-ORA-02095:
SQL> alter system set db_writer_processes=2;
alter system set db_writer_processes=2
*
ERROR at line 1:
ORA-02095: specified initialization parameter cannot be modified (this means par
ameter cannot be changed dynamically)
2-ORA-02096:
SQL> alter system set object_cache_optimal_size=204800;
alter system set object_cache_optimal_size=204800
*
ERROR at line 1:
ORA-02096: specified initialization parameter is not modifiable with this option
This happened because the parameter is deferred parameter and must be set with t
his option like below
SQL> alter system set object_cache_optimal_size=204800 deferred;
System altered.
3- ORA-32009
SQL> alter system reset control_file_record_keep_time scope=both sid= *';
alter system reset control_file_record_keep_time scope=both sid= *
*
ERROR at line 1:
ORA-32009: cannot reset the memory value for instance * from instance xe
Action is said Retry the query for the local instance if needed. (I tried it bel
ow but it gives me another error)
4- ORA-32010
SQL> alter system reset control_file_record_keep_time scope=both sid= xe ;
alter system reset control_file_record_keep_time scope=both sid= xe
*
ERROR at line 1:
ORA-32010: cannot find entry to delete in SPFILE
Action: Change the sid and/or the parameter. (I couldnt do it i think this is a
bug ?????)
5-ORA-00096:
SQL> alter system set log_archive_dest_state_1=1 scope=both;
alter system set log_archive_dest_state_1=1 scope=both
*
ERROR at line 1:
ORA-00096: invalid value 1 for parameter log_archive_dest_state_1, must be from
among alternate, reset, defer, enable
Footnote (07/07/2009) On Oracle 11G you dont need to put scope=spfile sid= * for re
setting the parameter.
SQL> alter system reset pga_aggregate_target;System altered.SQL> alter system re
set pga_aggregate_target;
System altered.
Alter system in Oracle

Alter system archive log [start|stop|all|...]
alter system archive log all;
alter system archive log next;
alter system archive log sequence 104;
alter system archive log current;
alter system archive log current noswitch;
The following command can be used to stop arch. alter system archive log stop
Similarly, arch is started with alter system archive log start
However, changing the archiver this way doesn't last when the database is restar
ted. When the database is started, it consults log_archive_start in the initiali
zation file to determine if arch is started. Alter system archive log all
This command is used to manually archive redo logs. alter system disconnect sess
ion
alter system kill session
alter system kill session 'session-id,session-serial'
This command kills a session. The session-id and session-serial parameters are f
ound in the v$session view (columns sid and serial#. alter system checkpoint
Performs a checkpoint alter system checkpoint
alter system dump datafile
This command can be used in order to dump one ore more blocks of a datafile. The
following command dumps blocks 50 through 55 of file 5. Which file 5 is can be
found out with v$datafile alter system dump datafile 5 block min 50 block max 55
;
Note: trace files are only readable by the Oracle account. If you want to change
this, set the undocumented initialization parameter _trace_files_public to true
. Doing so will, however, cause a big security risk. alter system flush buffer_c
ache
alter system flush buffer_cache;
This command is not available prior to 10g. It flushes the buffer cache in the S
GA. 9i had an undocumented command to flush the buffer cache: alter session set
events = 'immediate trace name flush_cache';
alter system flush shared_pool
alter system flush shared_pool;
This command flushed the shared pool. alter system quiesce restricted
alter system suspend|resume
alter system switch logfile
Causes a redo log switch. alter system switch logfile;
If the database is in archive log mode, but the ARCH process hasn't been started
m, the command might hang, because it waits for the archiving of the 'next' onli
ne redo log. alter system register
Forces the registration of database information with the listener. alter system
register
Alter system set timed_statistics
Setting timed_statistics=true might be usefule when using tk prof. Alter system
set sql_trace
Setting sql_trace=true is a prerequisite when using tk prof. Alter system set ..
.. deferred
Alter system can be used to change initialization parameters on system level. Ho
wever, some parameters, when changed with alter system don't affect sessions tha
t are already opened at the time when the statement is executet; it only affects
sessions started later. These parameters must be changed with alter system set
<initialization parameter> DEFERRED, otherwise a ORA-02096: specified initializa
tion parameter is not modifiable with this option error is returned. These param
eters can be identified as they have a DEFERRED in the isses_modifiable column o
f v$parameter. Alter system reset <parameter_name>
Resets a parameter. alter system reset some_param scope=both sid='*';
scope
scope=memory
Changes the parameter's value for the running instance only. As soon as the inst
ance is stopped and started, this change will be lost. scope=spfile
Alters an initialization parameter in the spfile scope=both
Alters an initialization parameter in the spfile as well as in the running insta
nce.
Remember, the parameter db_file_multiblock_read_count is only applicable for tab

les/indexes that are full scanned, but it also effects the SQL optimizer in its
calculation of the cost of a full-table scan.
According to Oracle, this is the formula for setting db_file_multiblock_read_cou
nt:
max I/O chunk size
db_file_multiblock_read_count = -------------------
db_block_size
But how do we know the value of the max I/O chunk size?
As of 10gR2, Oracle introduced 2 additional parameters relating to multi block r
ead count.
_db_file_optimizer_read_count: mbrc for optimizer
_db_file_exec_read_count: mbrc for execution
The purpose is more sophisticated mbrc management.
One thing you must keep in mind. Changing db_file_multiblock_read_count affects
both of the above parameters.Well documented here.
Now the real story goes.
One of my customers sent me following request.
Even when I change the db_file_multiblock_read_count in system level, optimizer i
gnores it.
Looks like a simple mistake or a new annoying bug. See following test case.
-- I don't have workload system stats!
SNAME PNAME PVAL1 PVAL2
------------------------------ -------------------- ---------- -----------------
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 02-26-2009 18:04
SYSSTATS_INFO DSTOP 02-26-2009 18:04
SYSSTATS_INFO FLAGS 0
SYSSTATS_MAIN CPUSPEEDNW 752.298
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR
create table t1(c1 int, c2 char(10));
insert into t1
select level, 'x'
from dual connect by level <= 100000
;
exec dbms_stats.gather_table_stats(user, 't1', no_invalidate=>false);
alter system set db_file_multiblock_read_count = 8;
explain plan for select /* 8 */ * from t1 where c1 = 1;
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 15 | 87 (3)| 00:00:02 |
|* 1 | TABLE ACCESS FULL| T1 | 1 | 15 | 87 (3)| 00:00:02 |
--------------------------------------------------------------------------
Ok, the FTS cost with 8 mbrc is 87. With bigger mbrc(16 here), Oracle should dec
rease the FTS cost. But
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Oops! Same cost? What s happening here?
This absolutely seems like an optimizer bug.
The interesting thing is that Oracle accepts the changed mbrc value when executi
ng multiblock read. This means that
Optimizer ignores _db_file_optimizer_read_count change at system level.
But query executor uses the changed _db_file_exec_read_count.
Very stupid, isn t it? I think there is a logic hole in handling these new paramet
ers(only 2!!!).
Solutions are
Session level changes are applied successfully
Change another (meaningless) system level optimizer parameter along with db_file_
multiblock_read_count
Following test case demonstrates the solution.
alter system set optimizer_mode = all_rows; -- meaningless change
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
alter system set optimizer_mode = all_rows; -- meaningless change
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
This bug(as I believe) is reproducible as of 10gR2 and 11g.
Starting 10gR2, db_file_multiblock_read_count is being set automatically depend

s on your OS I/O size and buffer cache size.
DB_FILE_MULTIBLOCK_READ_COUNT is one of the parameters you can use to minimize I
/O during table scans. It specifies the maximum number of blocks read in one I/O
operation during a sequential scan. The total number of I/Os needed to perform
a full table scan depends on such factors as the size of the table, the multiblo
ck read count, and whether parallel execution is being utilized for the operatio
n.
As of Oracle Database 10g release 2, the default value of this parameter is a va
lue that corresponds to the maximum I/O size that can be performed efficiently.
This value is platform-dependent and is 1MB for most platforms.Because the param
eter is expressed in blocks, it will be set to a value that is equal to the maxi
mum I/O size that can be performed efficiently divided by the standard block siz
e. Note that if the number of sessions is extremely large the multiblock read co
unt value is decreased to avoid the buffer cache getting flooded with too many t
able scan buffers.
Even though the default value may be a large value, the optimizer will not favor
large plans if you do not set this parameter. It would do so only if you explic
itly set this parameter to a large value.
Online transaction processing (OLTP) and batch environments typically have value
s in the range of 4 to 16 for this parameter. DSS and data warehouse environment
s tend to benefit most from maximizing the value of this parameter. The optimize
r is more likely to choose a full table scan over an index if the value of this
parameter is high.
The maximum value is the operating system's maximum I/O size expressed as Oracle
blocks ((max I/O size)/DB_BLOCK_SIZE). If you set this parameter to a value gre
ater than the maximum, Oracle uses the maximum.
******************************************************88
You said check x$kccle to find OS Block size.
I checked it which colum v hv to c.
is the column called
LESIZ or LELOS
in my case LESIZ = 40960.
in. Stay tuned for part 2 and the next level of advanced SQL statement tuning: s
tored outlines and SQL profiles!
March 20th, 2007 § 2 Comments

Last week I was in Houston teaching a class on 10g New Features and Performance
Tuning for a group of developers at a fairly large organization downtown. I try
to make my classes as interactive as possible and we had a number of interesting
discussions about topics such as appropriate uses for bitmap join indexes, IOT s,
and cluster tables in this organization s specific applications.
But there was one topic that kept coming up throughout the week. In the past, wh
en experiencing problems with query performance they d discovered that the RULE hi
nt seemed to make queries run faster. So they now have a large number of queries
that use the RULE hint and they re afraid to remove the hint for fear that their q
ueries will start to bomb. But since this hint is officially desupported in 10g
(although it still works) they are concerned about what to do when they upgrade.
Now you can in fact just leave the RULE hint in your queries. Oracle 10g will not
ignore the hint and your queries will work but they will not use new features in
Oracle such as bitmap indexes and Oracle Support will no longer help you troubl
eshoot them. So how do you control the way these SQL statements are executed? Th
ere are four methods for controlling SQL execution in Oracle 10g: rewriting the
SQL, hints, stored outlines and SQL profiles.
Rewrite the SQL
The oldest method for tuning SQL is still valid today albeit in a different way.
Unlike the old Rule Based Optimizer, the new Cost Based Optimizer ignores the o
rder of tables in the FROM clause (unless you ve specified the ORDERED hint) and i
t now has some fairly sophisticated query rewrite capabilities. But often the fi
rst step to tuning SQL is simply asking what am I trying to do and deciding if the
re s a simpler way to do it. For example, suppose you re trying to list all employee
s whose department is missing from the DEPT table. Perhaps the first method that
comes to mind is using a non-correlated subquery:
SQL> set autotrace traceonly explain
SQL> select * from emp
2 where deptno not in (select deptno from dept);
---------------------------------------------------------------------------
---------------------------------------------------------------------------
|* 1 | FILTER | | | | | |
| 2 | TABLE ACCESS FULL| EMP | 14 | 518 | 3 (0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| DEPT | 1 | 3 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------This
will work. But this is an example where you could simply rewrite your SQL statem
ent to get a better cost. For example, if you know that DNAME in the DEPT table
is never NULL then you could find the same information using an outer join rathe
r than a subquery:
SQL> select * from emp e, dept d
2 where e.deptno=d.deptno(+) and dname is null;
----------------------------------------------------------------------------
----------------------------------------------------------------------------
|* 1 | FILTER | | | | | |
|* 2 | HASH JOIN OUTER | | 14 | 798 | 7 (15)| 00:00:01 |
| 4 | TABLE ACCESS FULL| DEPT | 4 | 80 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------That
reduced the cost of the query from 12 to 7 great! But it s not exactly the same a
s the first query since we need to know that DNAME is not null. Now I excluded t
he predicate information from the very first query it show that Oracle is actual
ly transforming the non-correlated subquery to a correlated subquery. So lets se
e what happens if we just rewrite the query as a correlated query ourselves.
SQL> select * from emp e
2 where not exists (select 1 from dept d where d.deptno=e.deptno);
---------------------------------------------------------------------------
---------------------------------------------------------------------------
|* 1 | HASH JOIN ANTI | | 1 | 40 | 7 (15)| 00:00:01 |
---------------------------------------------------------------------------The s
ame improved cost as the outer join! Two important points about this: first, NOT
IN behaves differently than NOT EXISTS in the presence of NULL values. (In fact
this handling is why the first query was more expensive.) Second, always rememb
er that cost is what oracle predicts will happen not what actually will happen!
So remember to test the actual performance of these queries (perhaps with tkprof
). But this still a good example of how writing a query differently can change h
ow Oracle retrieves the answers to your questions.
Hints
Hints are integral to the CBO and are the oldest method of tuning cost-based SQL
statements; they were introduced with the CBO itself in Oracle 7. A hint makes
a suggestion to the optimizer about how to execute a query. If the hint doesn t ma
ke sense then the optimizer will ignore it and resume execution as usual. Hints
range from broad statement-level optimization approach hints to specific query-b
lock-level transformation hints. There are three hints that should be used judic
iously: ALL_ROWS, FIRST_ROWS, and APPEND (for data loads). All other hints shoul
d be used sparingly and their use should be justified.
As a quick example, suppose that you re reading all the employees and departments
with this query:
SQL> select * from emp e, dept d
2 where e.deptno=d.deptno;
---------------------------------------------------------------------------
---------------------------------------------------------------------------
|* 1 | HASH JOIN | | 14 | 798 | 7 (15)| 00:00:01 |
---------------------------------------------------------------------------If yo
u knew that your application was actually going to fetch only the first record t
hen you should tell the optimizer this. This is an example where you should use
a hint:
SQL> select /*+ first_rows(1) */ * from emp e, dept d
---------------------------------------------------------------------------
---------------------------------------------------------------------------
| 1 | NESTED LOOPS | | 1 | 57 | 4 (0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| EMP | 1 | 37 | 2 (0)| 00:00:01 |
---------------------------------------------------------------------------You c
an see that Oracle has now found a better way to execute your query, knowing wha
t you actually want. The cost reflects this adjustment.
It is also possible to control the execution at a more granular level. Suppose t
hat you specifically want to force Oracle to use a sort-merge join on these two
tables. You can use a hint to do just that:
SQL> select /*+ use_merge(e d) */ * from emp e, dept d
----------------------------------------------------------------------------
----------------------------------------------------------------------------
| 1 | MERGE JOIN | | 14 | 798 | 8 (25)| 00:00:01 |
| 2 | SORT JOIN | | 4 | 80 | 4 (25)| 00:00:01 |
|* 4 | SORT JOIN | | 14 | 518 | 4 (25)| 00:00:01 |
----------------------------------------------------------------------------Thes
e hints allow you to make decisions that are normally made by the optimizer and
should be used with care. However, that being said, hints are a very powerful to
ol for controlling how Oracle executes SQL statements. For more detailed informa
tion about hints, a good place to start is the Oracle Performance Tuning Guide.
Every developer who works on an Oracle database must have at least a basic under
standing of hints.
These first two methods are very powerful ways to control SQL execution. The cli
ent in Houston could certainly use hints other than RULE and achieve the exact s
ame execution plan and performance. However these two methods rest on one critic
al assumption: that you are able to control the SQL statements. What if you re run
ning a third party application which is generating SQL that you have no control
over? This is where the next two methods come in. Tuesday I wrote about a client
in Houston and removing the RULE hint from queries as part of their 10g migrati
on. This led into a discussion about the four ways to control SQL statement exec
ution: rewriting the SQL, hints, stored outlines and SQL profiles. I then discus
sed the first two methods rewriting SQL and using hints and gave examples of bot
h.
However these first two methods rest on the assumption that you are able to cont
rol the SQL statements. If you are using a third-party application where you do
not have control over the SQL statements that are generated then these methods w
ill not work. But fortunately Oracle introduced a feature almost 10 years ago in
8i release 1 (8.1.5) that can address this dilemma: stored outlines. Stored out
lines are an intriguing feature of Oracle that seem to be rather underutilized b
y the Oracle community in general. They re almost a throwback to the pre-oracle da
ys of compiled queries in the sense that you can specify and hardcode exactly ho
w you want a query to be executed.
Let s have a closer look.
Creating Stored Outlines
The most common usage of stored outlines is to achieve plan stability. In other
words, if you have already tuned your environment and want to make sure that not
hing changes then you can use stored outlines to lock the current plans in place.
After enabling the stored outlines the plans will not change when system paramet
ers change, new indexes are added, data distributions and statistics change or a
nything else happens that might normally cause a plan to change. Stored outlines
were originally designed with RBO to CBO transitions in mind; you could store t
he plans generated by the RBO before turning on the CBO and then incrementally r
eview the effects of removing outlines and letting the CBO optimize statements.
Internally, a stored outline is nothing more than a full set of hints. (That s why
you really need a thorough understanding of hints before you can master stored
outlines.) Outlines come in two flavors: PRIVATE and PUBLIC. Public outlines are
stored in the OUTLN schema and are activated system-wide (or session-only) by t
he setting USE_STORED_OUTLINES. Private outlines are primarily intended to be us
ed only temporarily while editing an outline and are activated with the session
parameter USE_PRIVATE_OUTLINES.
There are two methods for creating stored outlines: automatic and manual creatio
n. The most straightforward way to create a stored outline is manually with the
CREATE OUTLINE statement:
SQL> set autotrace traceonly explain;
SQL> create table test as select * from all_objects;
Table created.
SQL> exec dbms_stats.gather_table_stats('JEREMY','TEST');
PL/SQL procedure successfully completed.
SQL> variable id number;
SQL> exec :id:=1000;
SQL> select * from test where object_id=:id;
--------------------------------------------------------------------------
--------------------------------------------------------------------------
|* 1 | TABLE ACCESS FULL| TEST | 464 | 59392 | 160 (3)| 00:00:02 |
--------------------------------------------------------------------------
SQL> create outline on
2 select * from test where object_id=:id;
Outline created.
SQL> create index test_pk on test(object_id);
Index created.
--------------------------------------------------------------------------------
-------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Tim
e |
--------------------------------------------------------------------------------
-------
| 0 | SELECT STATEMENT | | 464 | 59392 | 4 (0)| 00:
00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 464 | 59392 | 4 (0)| 00:
00:01 |
|* 2 | INDEX RANGE SCAN | TEST_PK | 186 | | 1 (0)| 00:
00:01 |
--------------------------------------------------------------------------------
-------
SQL> alter session set use_stored_outlines=true;
Session altered.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------As you
can see, when stored outlines were enabled the plan reverted to the original pl
an that was saved before we created the index. Of course in real life you would
want to use the index but the point of this demo was to show plan stability, mea
ning that we could control plan changes.
The CREATE OUTLINE statement is convenient for demos, testing and individual sta
tements but there are at least two situations where it does not work well: if yo
u need to stabilize plans for an entire application that includes a large number
of statements and if you need to stabilize plans containing literals with the p
arameter CURSOR_SHARING set to SIMILAR or FORCE. Automatic outline creation can
address both of these situations. You only need to set the system or session par
ameter CREATE_STORED_OUTLINES and Oracle will automatically create and store an
outline for every single SQL statement processed.
SESSION 1
============
SQL> alter session set use_stored_outlines=false;
Session altered.
SESSION 2
============
SQL> alter system set create_stored_outlines=true;
System altered.
SESSION 1
============
SQL> select * from test where data_object_id=:id;
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
SESSION 2
============
SQL> alter system set create_stored_outlines=false
;
System altered.
SESSION 1
============
SQL> create index test_x2 on test(data_object_id);
Index created.
--------------------------------------------------------------------------------
-------
e |
--------------------------------------------------------------------------------
-------
| 0 | SELECT STATEMENT | | 464 | 59392 | 3 (0)| 00:
00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 464 | 59392 | 3 (0)| 00:
00:01 |
|* 2 | INDEX RANGE SCAN | TEST_X2 | 186 | | 1 (0)| 00:
00:01 |
--------------------------------------------------------------------------------
-------
SESSION 2
============
SQL> alter system set use_stored_outlines=true;
System altered.
SESSION 1
============
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------As you
can see from the output, the stored outline was automatically created as soon a
s the SQL statement was executed. Because we enabled outline creation system-wid
e the SQL could have been executed in any session by any user. One word of cauti
on; Oracle really will create a plan for every SQL statement executed by every u
ser so be careful! This could generate a lot of outlines! As you can see, after
we had created the outline we could enable it system-wide to achieve plan stabil
ity. Simple and very effective!
Should You Manipulate Stored Outlines
So far I ve shown how to nail down a satisfactory execution plan and prevent it fr
om changing. However I started out this article by saying that with outlines you
can specify and hardcode exactly how you want a query to be executed and I haven t
yet shown how this might be possible! In my opinion this is what makes stored ou
tlines such an amazing feature: the ability to edit your outline and effectively
make the optimizer execute your query in any legal way you can dream up. But my
prior warnings are still valid: this a dangerous capability. The optimizer is v
ery good at finding optimal execution paths and you should only override it when
you have a good reason for doing so.
Unfortunately there is some sad news here. The Oracle 9i Tuning Pack included pe
rhaps the coolest tool I have seen so far in Oracle: a graphical outline editor.
This java program, which was part of OEM, allowed you to choose your access pat
hs and join methods from drop-down lists and see a graphical representation of y
our plan. But it mysteriously disappeared from 10g and there don t appear to be an
y plans to include it again in the future. (haha plans )
There s one more bit of disheartening news. Usually Oracle is rather good about do
cumenting and exposing API s which are used by OEM and other graphical tools so yo
u can also perform these tasks from SQLPlus and from scripts. But in the case of
editing outlines there really is not an API simply a set of tables which need t
o be edited directly and the documentation is very sparse. There is one function
in the DBMS_OUTLN_EDIT to change a join position but it doesn t even seem to work i
n 10g. (It seems to update the TABLE_POS field in OL$HINTS and can apparently on
ly make the number smaller but not bigger. In 10g the LEADING hint specifies the
table order and this field seems to be ignored by the optimizer but I could easi
ly be missing something.) The performance tuning guide s example of editing an out
line alludes to directly editing the table ( if you want to change join order, mo
dify the appropriate LEADING hint ) but gives no examples or anything else helpfu
l. If you trace the 9i Outline Editor you will see that this is exactly what it s
doing: issuing DML against the user s private outline tables.
So can you edit these tables yourself to specify exactly what plan you want to u
se? This seems to be a fuzzy area regarding official support from Oracle. As I j
ust pointed out the 10gR2 manual specified that you should modify the LEADING hi
nt to change the join order so presumably Oracle would support this sort of mani
pulation. (Although clearly this section of the manual is severely out of date s
ince it still references the OEM Outline Editor which is no longer available in
10g.) However metalink note 122812.1 seems to indicate in its related documents
footer that the manipulating stored outlines as demonstrated in note 92201.1 is
not supported. So the moral of the story is that you should be very cautious and
careful if you choose to manipulate stored outlines; this is clearly a very pow
erful capability but it s unclear how much help you will get from Oracle support i
f you run into problems.
How To Manipulate Stored Outlines
Directly changing system tables in Oracle is always a delicate enterprise. Jonat
han Lewis article about Faking Stored Outlines concluded that in 9i it was no lon
ger safe to tamper much with Stored Outlines. Perhaps an examination of the trac
e files from the OEM Outline Editor could yield a wealth of information about sa
fely editing these files. Regardless, I will leave a discussion about more compl
icated edits for another time and in this article I will only demonstrate a simp
le manipulation like that in metalink note 144194.1.
To get started, lets create an additional table and a stored outline:
SQL> alter system set use_stored_outlines=false;
System altered.
SQL> create table lookup as
2 select object_type, max(object_name) name, count(*) data
3 from test group by object_type;
Table created.
SQL> create index test_fk on test(object_type);
Index created.
SQL> exec dbms_stats.gather_table_stats('JEREMY','LOOKUP');
SQL> select * from test t, lookup l where t.object_type=l.object_type;
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 46394 | 7656K| 164 (4)| 00:00:02 |
|* 1 | HASH JOIN | | 46394 | 7656K| 164 (4)| 00:00:02 |
| 2 | TABLE ACCESS FULL| LOOKUP | 36 | 1476 | 3 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL| TEST | 46394 | 5799K| 160 (3)| 00:00:02 |
-----------------------------------------------------------------------------
SQL> create private outline test2ol on
2 select * from test t, lookup l where t.object_type=l.object_type;
Outline created.
SQL> set autotrace off
SQL> select ol_name, hint#, hint_text from ol$hints order by ol_name,hint#;
OL_NAME HINT# HINT_TEXT
---------- ---------- -------------------------------------------------------
TEST2OL 1 USE_HASH(@"SEL$1" "T"@"SEL$1")
TEST2OL 2 LEADING(@"SEL$1" "L"@"SEL$1" "T"@"SEL$1")
TEST2OL 3 FULL(@"SEL$1" "T"@"SEL$1")
TEST2OL 4 FULL(@"SEL$1" "L"@"SEL$1")
TEST2OL 5 OUTLINE_LEAF(@"SEL$1")
TEST2OL 6 ALL_ROWS
TEST2OL 7 OPTIMIZER_FEATURES_ENABLE('10.2.0.1')
TEST2OL 8 IGNORE_OPTIM_EMBEDDED_HINTS
8 rows selected.Suppose we want to make two changes to the plan. First I want to
switch to a nested loop join and second I want to use the index-based access pa
th into the table TEST. Following the example from metalink all I need to do is
make two quick updates to the OL$HINTS table:
SQL> update ol$hints set hint_text='USE_NL(@"SEL$1" "T"@"SEL$1")'
2 where ol_name='TEST2OL' and hint#=1;
1 row updated.
SQL> update ol$hints set hint_text='INDEX(@"SEL$1" "T"@"SEL$1" ("TEST"."OBJECT_T
YPE"))'
2 where ol_name='TEST2OL' and hint#=3;
1 row updated.
SQL> commit;
Commit complete.
SQL> select ol_name, hint#, hint_text from ol$hints order by ol_name,hint#;
OL_NAME HINT# HINT_TEXT
---------- ---------- -------------------------------------------------------
TEST2OL 1 USE_NL(@"SEL$1" "T"@"SEL$1")
TEST2OL 2 LEADING(@"SEL$1" "L"@"SEL$1" "T"@"SEL$1")
TEST2OL 3 INDEX(@"SEL$1" "T"@"SEL$1" ("TEST"."OBJECT_TYPE"))
TEST2OL 4 FULL(@"SEL$1" "L"@"SEL$1")
TEST2OL 5 OUTLINE_LEAF(@"SEL$1")
TEST2OL 6 ALL_ROWS
TEST2OL 7 OPTIMIZER_FEATURES_ENABLE('10.2.0.1')
TEST2OL 8 IGNORE_OPTIM_EMBEDDED_HINTS
8 rows selected.
SQL> alter session set use_private_outlines=true;
Session altered.
SQL> select * from test t, lookup l where t.object_type=l.object_type;
--------------------------------------------------------------------------------
-------
e |
--------------------------------------------------------------------------------
-------
| 0 | SELECT STATEMENT | | 49838 | 6035K| 2196 (1)| 00:
00:27 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1424 | 129K| 83 (0)| 00:
00:01 |
| 2 | NESTED LOOPS | | 49838 | 6035K| 2196 (1)| 00:
00:27 |
| 3 | TABLE ACCESS FULL | LOOKUP | 35 | 1085 | 3 (0)| 00:
00:01 |
|* 4 | INDEX RANGE SCAN | TEST_FK | 1917 | | 3 (0)| 00:
00:01 |
--------------------------------------------------------------------------------
-------Shazam! We just specified and hardcoded exactly how we wanted the query t
o be executed. However there are two important notes about my example: first, a
FIRST_ROWS goal would have been a much much better way to create this outline. (
I.e. set the optimizer goal to FIRST_ROWS before creating the outline.) Second,
as Jonathan Lewis keenly points out in his paper, there are quite a few addition
al fields on the OL$HINTS table that appear to have some interdependencies with
the HINT_TEXT field. Just because a metalink note gives an example like this doe
sn t mean it s a great idea. Granted: it seems to work on Oracle 10.2.0.1.0 where I
tested it but we have definitely introduced a few internal inconsistencies by di
rectly editing these tables. Use this method with tremendous care.
The Future of Stored Outlines
I can t quite make out the future of stored outlines. The sorely lacking DBMS_OUTL
N_EDIT package has hardly been updated since 9i and I haven t yet found any mentio
n of outlines in 10g OEM. The fact that the Outline Manager/Editor was not inclu
ded in 10g also seems to indicate that Oracle is not continuing to develop this
feature. In metalink note 277066.1 (Overview Comparison of EM 9i to EM10g Featur
es) it is the only database management component which is not included in 10g.
Nonetheless, there are no indications that stored outlines will be desupported
in the near future. (Oracle does often give advanced warning about features that
are going to be desupported.) If this is a feature that could be useful to you
then you should take full advantage of it!
Stay tuned for part 2 and the next level of advanced SQL statement tuning: store
d outlines and SQL profiles!
******************
DB_FILE_MULTIBLOCK_READ_COUNT parameter helps determine how many blocks are read
at a time by the database during full table scans. You should set the DB_BLOCK_
MULTIBLOCK_READ_COUNT parameter to a value that takes the greatest advantage of
the operating system's buffer during reads. For example, suppose the OS buffer a
vailable for reads is 64KB in size. If your database block size is 2KB, you shou
ld set DB_FILE_MULTIBLOCK_READ_COUNT to 32; if the block size is 4KB, set DB_FIL
E_MULTIBLOCK_READ_COUNT to 16. In some operating systems, the available buffer s
ize is configurable.
DEFAULT: OS Dependent but usually a function of DB_BLOCK_BUFFERS and PROCESSES
VALUES: OS Dependent (normally 1 to either the DB_BLOCK_BUFFERS / 4 or the OS ma
ximum I/O size / DB_BLOCK_SIZE)
PROCESSES - For a multiple-process operation, this parameter specifies the maxim
um number of operating system user processes that can simultaneously connect to
an Oracle7 Server. Should include up to 6 for the background processes (or more
if GC_LCK_PROCS is non-zero or if you use the dispatcher configuration) plus one
for login; so a value of 20 would permit 13 or 14 concurrent users. The default
values of DB_FILE_MULTIBLOCK_READ_COUNT and SESSIONS are derived from PROCESSES
. If you alter the value of PROCESSES, you may want to adjust the values of thes
e derived parameters.
DEFAULT: 25
VALUES: 6 - OS Dependent
General Info
Here are some scripts related to general database information .
Database Information
DATABASE INFORMATION NOTES:
Database Name - Name of the database

Created - Date/time the database was created
Log Mode - Archive log mode: NOARCHIVELOG or ARCHIVELOG
Checkpoint Change# - Last SCN checkpointed
Archive Change# - Last SCN archived
select NAME,
CREATED,
LOG_MODE,
CHECKPOINT_CHANGE#,
ARCHIVE_CHANGE#
from v$database
Size
DATAFILE NOTES:
File Name - Name of the datafile

Tablespace - Name of the tablespace
Datafile Size - Size of datafile (bytes)
Bytes Used - Amount of datafile used
Percent Used - Percent of datafile used
Bytes Free - Amount of datafile free
select FILE_NAME,
d.TABLESPACE_NAME,
d.BYTES datafile_size,
nvl(sum(e.BYTES),0) bytes_used,
round(nvl(sum(e.BYTES),0) / (d.BYTES), 4) * 100 percent_used,
d.BYTES - nvl(sum(e.BYTES),0) bytes_free
from DBA_EXTENTS e,
DBA_DATA_FILES d
where d.FILE_ID = e.FILE_ID (+)
group by FILE_NAME,d.TABLESPACE_NAME, d.FILE_ID, d.BYTES, STATUS
order by d.TABLESPACE_NAME,d.FILE_ID
Files
DATABASE FILE NOTES:
Filename - Name of the file(s)

Location - Location of the file(s)
select 'Archived Log Directory' "Filename",
value "Location"
from v$parameter
where name = 'log_archive_dest'
UNION
select 'Control Files' "Filename",
value "Location"
from v$parameter
where name = 'control_files'
UNION
select 'Datafile' "Filename",
name "Location"
from v$datafile
UNION
select 'LogFile Member' "Filename",
member "Location"
from v$logfile
init.ora
INIT.ORA PARAMETER NOTES:
Parameter - Init.ora parameter name
Value - Current value
Is Default - Whether the parameter value is the default
Session Modifiable - TRUE=the parameter can be changed with ALTER SESSION / FALSE
=the parameter cannot be changed with ALTER SESSION
System Modifiable - IMMEDIATE=the parameter can be changed with ALTER SYSTEM / DE
FERRED=the parameter cannot be changed until the next session / FALSE=the parame
ter cannot be changed with ALTER SYSTEM
Is Modified - Indicates how the parameter was modified. If an ALTER SESSION was p
erformed, the value will be MODIFIED. If an ALTER SYSTEM (which will cause all t
he currently logged in sessions' values to be modified) was performed the value
will be SYS_MODIFIED.
ALWAYS_ANTI_JOIN - Set the parameter to HASH to allow parallel processing of the
NOT IN clause (a real resource hog). If you set the parameter to NESTED_LOOPS, t
he NOT IN is evaluated the same way it was as Oracle7.2 and earlier (which will
not please you). MERGE uses the SORT_MERGE algorithm to process the NOT IN, whic
h is faster than NESTED_LOOPS but not as fast as HASH.
DEFAULT: NULL
VALUES: NESTED_LOOPS, MERGE, HASH
COMPATIBLE - This parameter specifies the release with which the Oracle Server mu
st maintain compatibility. Set to the release of Oracle RDBMS that you are curre
ntly running to take full advantage of any new features. Allows you to use the c
urrent version while at the same time guaranteeing backward compatibility with a
n earlier release. This is in case it becomes necessary to revert to the earlier
release. Some features of the current release may be restricted. Oracle 7.1.5 i
ntroduced the ability to bypass the buffer cache (direct reads) for table scans
and sorts (COMPATIBLE=7.1.5). Oracle 7.3 introduced temporary tablespaces that i
mprove the performance of sorts and hash joins (COMPATIBLE=7.3.1)
DEFAULT: NULL
VALUES: Any Oracle RDBMS (e.g., Oracle7.2.3)
CONTROL_FILES - Specifies one or more names of control files, separated by commas
. Oracle Corporation recommends using multiple files on different devices or mir
roring the file at the OS level.
DEFAULT: OS Dependent
VALUES: 1 - 8 filenames
CURSOR_SPACE_FOR_TIME - Turns waiting for application cursors on (TRUE) or off (F
ALSE). If it is set to TRUE, the database uses more space for cursors to save ti
me. It affects both the shared SQL area and the client's private SQL area. Share
d SQL areas are kept pinned in the shared pool when this parameter's value is TR
UE. As a result, shared SQL areas are not aged out of the pool as long as there
is an open cursor that references them. Because each active cursor's SQL area is
present in memory, execution is faster. Because the shared SQL areas never leav
e memory while they are in use, however, you should set this parameter to TRUE o
nly when the shared pool is large enough to hold all open cursors simultaneously
. Setting this parameter to TRUE also retains the private SQL area allocated for
each cursor between executes instead of discarding it after cursor execution. T
his saves cursor allocation and initialization time.
DEFAULT: FALSE
VALUES: TRUE/FALSE
DB_BLOCK_BUFFERS - Sets the size, in database blocks, of the data block buffer ca
che in the SGA. The larger the data block buffer cache is, the more memory will
be available for sharing data already in memory amoung users - reducing the need
for physical reads. You can determine the effectiveness of the data block buffe
r cache by measuring the hit ratio of the database.
DEFAULT: 32 Buffers
VALUES: 4 to unlimited
DB_BLOCK_SIZE - Defined when the database is created; it determines the size of e
ach block within the database. You CANNOT change the block size of an existing d
atabase; the only method available for increasing the block size is to perform a
full database Export, recreate the database with a different DB_BLOCK_SIZE valu
e, and Import the database. In most environments, the default value for DB_BLOCK
_SIZE is 2048 bytes (2KB). If you operating environment permits, you should incr
ease the value to 4KB, 8KB, or higher. The performance gains obtained by using a
larger block size are significant for both OLTP and batch applications. In gene
ral, each doubling of the database block size will reduce the time required for
I/O-intensive batch operations be around 40 percent. As the database block size
increases, your overall memory requirements may increase.
VALUES: 1024-32768
DB_FILE_MULTIBLOCK_READ_COUNT parameter helps determine how many blocks are read
at a time by the database during full table scans. You should set the DB_BLOCK_M
ULTIBLOCK_READ_COUNT parameter to a value that takes the greatest advantage of t
he operating system's buffer during reads. For example, suppose the OS buffer av
ailable for reads is 64KB in size. If your database block size is 2KB, you shoul
d set DB_FILE_MULTIBLOCK_READ_COUNT to 32; if the block size is 4KB, set DB_FILE
_MULTIBLOCK_READ_COUNT to 16. In some operating systems, the available buffer si
ze is configurable.
DEFAULT: OS Dependent but usually a function of DB_BLOCK_BUFFERS and PROCESSES
VALUES: OS Dependent (normally 1 to either the DB_BLOCK_BUFFERS / 4 or the OS ma
ximum I/O size / DB_BLOCK_SIZE)
DB_FILE_SIMULTANEOUS_WRITES - Number of write batches written by the database wri
ters. If you are experiencing problems getting buffers written to your disks dur
ing checkpoints, try increasing the value. It is applicable only to the operatio
n systems that support more than one write to your disk devices.
DEFAULT: 4
VALUES: 1 to 24
DB_WRITERS - Once the database block size and memory areas are properly establish
ed, tune the way in which Oracle writes data from memory. If your OS permits usi
ng multiple DBWR processes, set a value greater than '1' for the DB_WRITERS para
meter. If you start more than on DBWR process, you may be able to reduce content
ion for blocks within the database block buffer cache. If there is only one DBWR
process available, it becomes a possible bottleneck during I/O operations, even
if the data is distributed among multiple devices.
ENQUEUE_RESOURCES - An enqueue is a sophisticated locking mechanism which permits
several concurrent processes to share known resources to varying degrees. Any o
bject which can be used concurrently can be protected with enqueues. For example
, Oracle allows varying levels of sharing on tables: two processes can lock a ta
ble in share mode or in share update mode.
DEFAULT: Derived
VALUES: 10 - 65535
HASH_AREA_SIZE - This parameter specifies the maximum amount of memory, in bytes,
to be used for the hash join. If this parameter is not set, its value defaults
to twice the value of the SORT_AREA_SIZE parameter. You can change the value of
this parameter without shutting down your Oracle instance by using the ALTER SES
SION command.
DEFAULT: 2 times the value of SORT_AREA_SIZE
VALUES: Any integer
HASH_JOIN_ENABLED - This parameter enables or disables the hash join feature. Set
this parameter to TRUE to use hash joins. Set this parameter to FALSE to disabl
e hash joins. You can change the value of this parameter without shutting down y
our Oracle instance by using the ALTER SESSION command.
DEFAULT: TRUE
VALUES: TRUE/FALSE
HASH_MULTIBLOCK_IO_COUNT - This parameter specifies how many blocks a hash join r
eads and writes at once. When operating in multi-threaded server mode, however,
this parameter is ignored (that is, the default value of 1 is used even if you s
et the parameter to another value). The value of DB_BLOCK_SIZE multiplied by the
value of HASH_MULTIBLOCK_IO_COUNT should be less than 64 KB. This parameter str
ongly affects performance because it controls the number of partitions into whic
h the input is divided.
DEFAULT: 1
VALUES: 1 - (65,536/DB_BLOCK_SIZE)
LOG_ARCHIVE_BUFFER_SIZE - The size of each archival buffer, in redo log blocks (o
perating system blocks). The default should be adequate for most applications. T
his parameter, with LOG_ARCHIVE_BUFFERS, can tune archiving so that it runs as f
ast as necessary, but not so fast that it reduces system performance.
VALUES: 1 - OS Dependent (in O/S blocks)
LOG_ARCHIVE_DEST - Applicable only if using the redo log in ARCHIVELOG mode. Use
a text string to specify the default location and root of the disk file or tape
device when archiving redo log files. (Archiving to tape is not supported on all
operating systems.) The value cannot be a raw partition. To override the destin
ation that this parameter specifies, either specify a different destination for
manual archiving or use the Server Manager command ARCHIVE LOG START filespec fo
r automatic archiving, where filespec is the new archive destination.
VALUES: Any valid path or device name, except raw partitions
LOG_ARCHIVE_START - Applicable only when you use the redo log in ARCHIVELOG mode,
LOG_ARCHIVE_START indicates whether archiving should be automatic or manual whe
n the instance starts up. TRUE indicates that archiving is automatic. FALSE indi
cates that the DBA will archive filled redo log files manually. (The Server Mana
ger command ARCHIVE LOG START or STOP overrides this parameter.) In ARCHIVELOG m
ode, if all online redo log files fill without being archived, an error message
is issued, and instance operations are suspended until the necessary archiving i
s performed. This delay is more likely if you use manual archiving. You can redu
ce its likelihood by increasing the number of online redo log files.
DEFAULT: FALSE
VALUES: TRUE/FALSE
LOG_BUFFER Sets the size, in bytes, of the redo log buffer area in the SGA. The d
efault is set to four times the maximum database block size for the OS. For an O
LTP application in which many users perform transactions, the LOG_BUFFER paramet
er needs to be increased beyond its default value. If the 'redo log space reques
ts' statistic in V$SYSSTAT is non-zero, you should increase LOG BUFFER to suppor
t the transaction load without forcing transactions to wait for accesses to the
redo log buffer.
VALUES: OS Dependent
LOG_CHECKPOINT_INTERVAL - The number of newly filled redo log file blocks needed
to trigger a checkpoint. Regardless of this value, a checkpoint always occurs wh
en switching from one online redo log file to another. If the value exceeds the
actual redo log file size, checkpoints occur only when switching logs. The numbe
r of times DBWR has been notified to do a checkpoint for a given instance is sho
wn in the cache statistic dbwr checkpoints, which is displayed in the System Sta
tistics Monitor of the Server Manager. Additional cache statistics include backg
round checkpoints started and background checkpoints completed.
VALUES: Unlimited (OS blocks, not database blocks)
LOG_SIMULTANEOUS_COPIES - The maximum number of redo buffer copy latches availabl
e to write log entries simultaneously. For good performance, you can have up to
twice as many redo copy latches as CPUs. For a single-processor system, set to z
ero so that all log entries are copied on the redo allocation latch. If this par
ameter is set to 0, redo copy latches are turned off, and the parameters LOG_ENT
RY_PREBUILD_THRESHOLD and LOG_SMALL_ENTRY_MAX_SIZE are ignored. You can change t
he value of this parameter without shutting down your Oracle instance by using t
he ALTER SESSION command.
DEFAULT: CPU_COUNT
VALUES: 0 - unlimited
OPTIMIZER_MODE - When set to RULE, this parameter causes rule-based optimization
to be used unless hints are specified in the query. When set to CHOOSE, the opti
mizer uses the cost-based approach for a SQL statement if there are statistics i
n the dictionary for at least one table accessed in the statement. (Otherwise, t
he rule-based approach is used.) You can set the goal for cost-based optimizatio
n by setting this parameter to FIRST_ROWS or ALL_ROWS. FIRST_ROWS causes the opt
imizer to choose execution plans that minimize response time. ALL_ROWS causes th
e optimizer to choose execution plans that minimize total execution time. The go
al of cost-based optimization can also be set within a session by using ALTER SE
SSION SET OPTIMIZER_MODE.
DEFAULT: CHOOSE
VALUES: RULE/CHOOSE/FIRST_ROWS/ALL_ROWS
PARALLEL_MAX_SERVERS - Each instance must either have a value of zero or the same
value as the other instances. Maximum number of query servers or parallel recov
ery processes for an instance.
VALUES: 0 - 256
PARALLEL_MIN_SERVERS - Minimum number of query server processes for an instance.
This is also the number of query server processes Oracle creates when the instan
ce is started.
DEFAULT: 0
VALUES: 0 - PARALLEL_MAX_SERVERS
PROCESSES - For a multiple-process operation, this parameter specifies the maximu
m number of operating system user processes that can simultaneously connect to a
n Oracle7 Server. Should include up to 6 for the background processes (or more i
f GC_LCK_PROCS is non-zero or if you use the dispatcher configuration) plus one
for login; so a value of 20 would permit 13 or 14 concurrent users. The default
values of DB_FILE_MULTIBLOCK_READ_COUNT and SESSIONS are derived from PROCESSES.
If you alter the value of PROCESSES, you may want to adjust the values of these
derived parameters.
DEFAULT: 25
VALUES: 6 - OS Dependent
ROLLBACK_SEGMENTS - One or more rollback segments to allocate by name to this ins
tance. If ROLLBACK_SEGMENTS is not overridden, an instance acquires all of the r
ollback segments named in this parameter, even if the number of rollback segment
s exceeds the minimum number required by the instance (calculated from the ratio
TRANSACTIONS / TRANSACTIONS_PER_ROLLBACK_SEGMENT).
DEFAULT: NULL (the instance uses public rollback segments by default if you do n
ot specify this parameter
VALUES: Any rollback segment names listed in DBA_ROLLBACK_SEGS except SYSTEM
ROW_CACHE_CURSORS - The number of cached recursive cursors used by the row cache
manager for selecting rows from the data dictionary. The default value is suffic
ient for most systems.
DEFAULT: 10
VALUES: 10 - 3300
SHARED_POOL_RESERVED_MIN_ALLOC - This parameter controls allocation of reserved m
emory. Memory allocations larger than this value can allocate space from the res
erved list if a chunk of memory of sufficient size is not found on the shared po
ol free lists. The default value is adequate for most systems. If you increase t
he value, then the Oracle Server will allow fewer allocations from the reserved
list and will request more memory from the shared pool list.
DEFAULT: 5000
VALUES: 5000 - SHARED_POOL_RESERVED_SIZE (in bytes)
SHARED_POOL_RESERVED_SIZE - This parameter controls the amount of SHARED_POOL_SIZ
E reserved for large allocations. SHARED_POOL_RESERVED_SIZE must be greater than
SHARED_POOL_RESERVED_MIN_ALLOC to create a reserved list. The default value of
0 represents no reserved shared pool area. Ideally, this parameter should be lar
ge enough to satisfy any request scanning for memory on the reserved list withou
t flushing objects from the shared pool. The amount of operating system memory,
however, may constrain the size of the shared pool. In general, you should set S
HARED_POOL_RESERVED_SIZE to 10% of SHARED_POOL_SIZE. For most systems, this valu
e will be sufficient if you have already tuned the shared pool.
DEFAULT: 0
VALUES: From SHARED_POOL_RESERVED_MIN_ALLOC to one half of SHARED_POOL_SIZE (in
bytes)
SHARED_POOL_SIZE - Sets the size, in bytes, of the shared pool in the SGA. If you
r application is OLTP-oriented, and you use packages and other procedural object
s, you'll need a large shared SQL area. In environments using a large number of
procedural objects, the size of your shared pool may exceed your data block buff
er cache. If you have many users, you should increase the SHARED_POOL_SIZE param
eter everytime you increase the DB_BLOCK_BUFFERS parameter.
DEFAULT: 3,500,000
VALUES: 300 Kbytes - OS Dependent
SORT_AREA_RETAINED_SIZE - This parameter specifies the maximum amount, in bytes,
of Program Global Area (PGA) memory retained after a sort. This memory is releas
ed back to the PGA, not to the operating system, after the last row is fetched f
rom the sort space. If a sort requires more memory, a temporary segment is alloc
ated and the sort becomes an external (disk) sort. The maximum amount of memory
to use for the sort is then specified by SORT_AREA_SIZE instead of by this param
eter. Larger values permit more sorts to be performed in memory. However, multip
le sort spaces of this size may be allocated. Usually, only one or two sorts occ
ur at one time, even for complex queries. In some cases, though, additional conc
urrent sorts are required. Each sort occurs in its own memory area, as specified
by SORT_AREA_RETAINED_SIZE.
DEFAULT: The value of SORT_AREA_SIZE
VALUES: From the value equivalent to one database block to the value of SORT_ARE
A_SIZE
SORT_AREA_SIZE - This parameter specifies the maximum amount, in bytes, of Progra
m Global Area (PGA) memory to use for a sort. After the sort is complete and all
that remains to do is to fetch the rows out, the memory is released down to the
size specified by SORT_AREA_RETAINED_SIZE. After the last row is fetched out, a
ll memory is freed. The memory is released back to the PGA, not to the operating
system. Increasing SORT_AREA_SIZE size improves the efficiency of large sorts.
Multiple allocations never exist; there is only one memory area of SORT_AREA_SIZ
E for each user process at any time. The default is usually adequate for most da
tabase operations. Only if very large indexes are created might you want to adju
st this parameter. For example, if one process is doing all database access, as
in a full database import, then an increased value for this parameter may speed
the import, particularly the CREATE INDEX statements.
VALUES: The value equivalent to two database blocks (minimum)
SORT_DIRECT_WRITES - SORT_DIRECT_WRITES can improve sort performance if memory an
d temporary space are abundant on your system. When set to the default value of
AUTO, and if the value of SORT_AREA_SIZE is greater than ten times the buffer si
ze, SORT_DIRECT_WRITES automatically configures the SORT_WRITE_BUFFER_SIZE and S
ORT_WRITE_BUFFERS parameters. When SORT_DIRECT_WRITES is in AUTO mode, SORT_WRIT
E_BUFFERS and SORT_WRITE_BUFFER_SIZE have no effect. When SORT_DIRECT_WRITES is
set to TRUE, each sort allocates additional buffers in memory to write directly
to disk. When SORT_DIRECT_WRITES is set to FALSE, the sorts that write to disk w
rite through the buffer cache.
DEFAULT: AUTO
VALUES: AUTO/TRUE/FALSE
SORT_READ_FAC - SORT_READ_FAC is a unitless ratio that describes the amount of ti
me to read a single database block divided by the block transfer rate.
SORT_WRITE_BUFFER_SIZE - This parameter sets the size of the sort buffer when the
SORT_DIRECT_WRITES parameter is set to TRUE. This parameter is recommended for
use with symmetric replication.
DEFAULT: 32768
VALUES: Any integer
SORT_WRITE_BUFFERS - This parameter sets the number of sort buffers when the SORT
_DIRECT_WRITES parameter is set to TRUE. This parameter is recommended for use w
ith symmetric replication.
DEFAULT: 2
VALUES: Any integer
SQL_TRACE - Disables or enables the SQL trace facility. Setting this parameter to
TRUE provides information on tuning that you can use to improve performance. Be
cause the SQL trace facility causes system overhead, you should run the database
with the value TRUE only for the purpose of collecting statistics. You can chan
ge the value of this parameter without shutting down your Oracle instance by usi
ng the ALTER SESSION command.
DEFAULT: FALSE
VALUES: TRUE/FALSE
TIMED_STATISTICS - By default (when set to FALSE), the Server Manager statistics
related to time (from the buffer manager) always are zero and the Server can avo
id the overhead of requesting the time from the operating system. To turn on sta
tistics, set the value to TRUE. Should normally be set to FALSE.
DEFAULT: FALSE
VALUES: TRUE/FALSE
USER_DUMP_DEST - The pathname for a directory where the server will write debuggi
ng trace files on behalf of a user process.
VALUES: Valid local pathname, directory, or disk
select NAME,
VALUE,
ISDEFAULT,
ISSES_MODIFIABLE,
ISMODIFIED
from v$parameter
order by NAME
License
LICENSE INFORMATION NOTES:
Sessions Max - Maximum number of concurrent user sessions allowed for the instanc
e.
Sessions Warn - Warning limit for concurrent user sessions for the instance.
Sessions Current - Current number of concurrent user sessions.
Sessions Highwater - Highest number of concurrent user sessions sine the instance
started.
Users Max - Maximum number of named users allowed for the database.
select SESSIONS_MAX,
SESSIONS_WARNING,
SESSIONS_CURRENT,
SESSIONS_HIGHWATER,
USERS_MAX
from v$license
Versions
DATABASE PRODUCT AND VERSION NOTES:
Version number of core library components in the Oracle Server

select BANNER product_versions
from v$version
Oracle 10g
As of the time of this writing, I know only little about Oracle 10g's new feat
ures, but I intend to put them here as soon as I know more. The G stands for Gri
d Computing. A common missconception seems to be that grid is just the new name
for RAC (having improved RAC). This is not the case. 10g comes with both RAC and
grid. One will be able to install 10g with RAC only or with grid only, without
either and with both.
There is a profound difference between grid and RAC. 10g is said to have 149 new
features. Possibly, the most popular will be the model clause and the transport
able tablespaces. The SQL*PLUS copy command will be deprecated. SQL Model Clause
. This will enhance SQL for calculations. SQL result sets can be treated like mu
ltidimensional arrays. HTML DB (previously known as Project Marvel) will be a RA
D environment for web-based applications. PHP will be supported SQL: Regular Exp
ressions (finally), native numbers (based on IEEE 754), enhancements for LOBs, e
nhancements for collections.
It should be noted, however, that regular expressions were available through the
owa_pattern package. Data Pump replaces EXP and IMP. It provides high speed, pa
rallel, bulk data and metadata movement of Oracle database contents across platf
orms and database versions. If a data pump job is started and fails for any reas
on before it has finished, it can be restarted at a later time. ASM: automatic s
torage management. Flashback database: old database block images are stored in a
Flash Recovery Area which allow fast rollbacks of database (as no online redo l
ogs are required.)
Flash Back Database makes it also possible to correct user errors: undropping ta
bles. Automatic Shared Memory Management is another self-management enhancement
to Oracle. It includes a new parameter: sga_target. A myriad of advisors:
SQL tuning advisor
See also dbms_sqltune
SQL access advisor
Memory advisors
Segment advisor
hanling space-related questions (predictions of table/index sizes, analzying gro
wth trends)
Undo advisor
Helping to estimate the size for undo.
The 'help' of the advisors is exposed through dba_advisor_findings, dba_advisor_
recommendations, dba_advisor_rationale and many more. An alert infrastructure co
mplements these advisors. DBA's will be notified when a problem occurs and a rec
ommondation for corrective actions will be delivered. ADDM: Automatic database d
iagnostic monitor. ADDM enables Oracle to diagnose its own performance problems.
For example, ADDM identifies the most resource intensive SQL statements and pass
es that statement to the SQL tuning advisor. AWR: automatic workload repository.
AWR periodically gathers and stores system activity and workload data which is
then analysed by ADDM.
Every layer of Oracle is now equipped with instrumentation that gathers informat
ion on workload which will then be used to make self-managing decisions. AWR is
the place where this data is stored. trcsess is a tool that gathers SQL from ses
sions in a shared server environment. Improved Timing and Statistics through:
v$eventmetric,
v$sessmetric,
v$sysmetric,
v$filemetric,
v$sysmetric_history and
v$session_wait_history
statspack will be somewhat obsolete with 10g although it is still around. It's f
unctionality is "taken over" by the Oracle kernel and the results can be made vi
sible with enterprise manager (EM). Misc changes
The buffer cache can be flushed with alter system flush buffer_cache. dbms_job i
s going to be replaced by dbms_scheduler. Calendar Expressions (through / within
???) dbms_scheduler : Yearly, Monthly, Weekly, Daily, Hourly, Minutely, Secondel
y. drop database gets rid of datafiles online redo log files, controlfiles and s
pfile. New pl/sql data types: binary_float and binary_double (IEEE). plsql_optim
ize_level. Default User tablespace. A default user tablespace allows to define a
tablespace that will be the default tablespaces for users created afterwards. T
hose users will then not have the system tablespace as their default tablespace.
This concept is similar to that of default temporary tablespace in 9i. Tablespac
e groups Renaming tablespaces (even read only ones). Larger LOBS: (4GB - 1) * de
fault block size. Bigfile tablespaces : create bigfile tablespace beeeg_ts data
file '/o1/dat/beeeg.dbf' size 2T. The sysaux tablespace. Transportable tablespac
es can now operate across platforms with convert tablespace. utl_mail and utl_co
mpress. The RBO is definitely dead and CBO is the only optimizer. Three new oper
ators enhance hierarchical queries: connect_by_root, connect_by_isleaf and conne
ct_by_iscycle. A new background process: MMON. dbms_sqltune. Capturing bind vari
ables with v$sql_bind_capture. v$session now exposing the information of v$sessi
on_wait (event, p1, p2, p3) spool now with three options: create, replace and ap
pend. The sqlprompt can dynamically be set at runtime. glogin.sql and login.sql
executed also on connect. Case and accent insensitive queries if parameter nls_c
omp = ansi and nls_sort = generic_m_ai. (See also On case insensitive queries in
10g.) The GUI version of windows SQL*PLUS FINALLY removed. Basic Init Parameter
s
compatible, control_files, db_block_size, db_create_file_dest, db_create_online_
log_dest, db_domain, db_name, db_recovery_file_dest, db_recovery_file_dest_size,
instance_number, job_queue_processes, log_archive_dest_n, log_archive_dest_stat
e_n, nls_language, nls_territory, open_cursors, pga_aggregate_target, processes,
remote_listener, remote_login_passwordfile, rollback_segments, sessions, shared
_servers, sga_target, star_transformation_enabled, undo_management and undo_tabl
espace Developing Oracle 10g
According to Andy Mendelsohn (senior vice president in Oracle's Database and App
lication Server Technologies group), one of the goals for 10g was to deliver a c
omplete, integrated stack of software so as to make it possible for Oracle users
to not have to depend anymore on third party software. This lead to twelve (ele
ven??) development focus areas for 10g:
Application Development
Business Intelligence and Data Warehousing Clustering
Content Management
High Availability
Information Integration
Life Sciences
Location Services
Performance and Scalability
Security and Directory
Server Manageability
Windows
Property Description
Parameter type String
Syntax QUERY_REWRITE_INTEGRITY = { enforced | trusted | stale_tolerated }
Default value enforced
Modifiable ALTER SESSION, ALTER SYSTEM
Real Application Clusters Multiple instances can have different values.
QUERY_REWRITE_INTEGRITY determines the degree to which Oracle must enforce query

rewriting. At the safest level, Oracle does not use query rewrite transformatio
ns that rely on unenforced relationships.
Values:
enforced
Oracle enforces and guarantees consistency and integrity.
trusted
Oracle allows rewrites using relationships that have been declared, but that are
not enforced by Oracle.
stale_tolerated
Oracle allows rewrites using unenforced relationships. Materialized views are el
igible for rewrite even if they are known to be inconsistent with the underlying
detail data.
PARALLEL_THREADS_PER_CPUProperty Description
Parameter type Integer
Default value Operating system-dependent, usually 2
Modifiable ALTER SYSTEM
Range of values Any nonzero number
Note:
This parameter applies to parallel execution in exclusive mode as well as in a R
eal Application Clusters environment.
PARALLEL_THREADS_PER_CPU specifies the default degree of parallelism for the ins
tance and determines the parallel adaptive and load balancing algorithms. The pa
rameter describes the number of parallel execution processes or threads that a C
PU can handle during parallel execution.
The default is platform-dependent and is adequate in most cases. You should decr
ease the value of this parameter if the machine appears to be overloaded when a
representative parallel query is executed. You should increase the value if the
system is I/O bound.
What is PGA_AGGREGATE_TARGET?
This parameter controls the maximum amount of memory PGA which can be used by th
e queries when WORKAREA_SIZE_POLICY is set to Auto.
The value you can be set in Bytes, kilobytes (K), megabytes (M) or gigabytes (G)
. The default value is 0
This parameter also has an effect on the execution plans of the cost based optim
izer. The optimizer uses the value of the parameter PGA_AGGREGATE_TARGET to deri
ve an estimate
for the minimum and maximum amount of memory which should be available at run-ti
me for each sort, hash-join and bitmap operator in the query. Based on this mini
mum and maximum value, the
optimizer selects the best plan.
Question : How do you analyze table partition using Oracle provided package?
DBMS_STATS.GATHER_TABLE_STATS with GRANULARITY => 'PARTITION' OPTION
How to know the last executed procedure?
Execute procedure name (parameter1,parameter2)
Select timestamps, owner, obj_name, action_name from dba_audit_trail;this statem
ent gives last executed time for procedure , function & package.
>
SQL> DECLARE
2 e_MissingNull EXCEPTION;
3 PRAGMA EXCEPTION_INIT(e_MissingNull, -1400);
4 BEGIN
5 INSERT INTO e (vk) VALUES (NULL);
6 EXCEPTION
7 WHEN e_MissingNull then
8 DBMS_OUTPUT.put_line('ORA-1400 occurred');
9 WHEN OTHERS THEN
10 DBMS_OUTPUT.put_line('Others occurred');
11 END;
12 /
ORA-1400 occurred
PL/SQL procedure successfully completed
A user account is identified by a user name and defines the user's attributes, i
ncluding the following:
What Is a User Account in Oracle?
A user account is identified by a user name and defines the user's attributes, i
ncluding the following:
* Password for database authentication
* Privileges and roles
* Default tablespace for database objects
* Default temporary tablespace for query processing work space
What Is the Relation of a User Account and a Schema in Oracle?
User accounts and schemas have a one-to-one relation. When you create a user, yo
u are also implicitly creating a schema for that user. A schema is a logical con
tainer for the database objects (such as tables, views, triggers, and so on) tha
t the user creates. The schema name is the same as the user name, and can be use
d to unambiguously refer to objects owned by the user.
What Is Transport Network Substrate (TNS) in Oracle?
TNS, Transport Network Substrate, is a foundation technology, built into the Ora
cle Net foundation layer that works with any standard network transport protocol
.

All Rows

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

All Rows

Transféré par

Droits d'auteur :

Formats disponibles

select cache/tot*100 "Session cursor cache%"

system restart required.

Glad that you have tracked down the problem.

Re: How to find current init.ora file

SQL> show parameter pfile

ALTER SYSTEM SET optimizer_mode=RULE SCOPE = SPFILE;

SQL> alter system reset timed_statistics scope=spfile sid='*';

Alter system in Oracle

Remember, the parameter db_file_multiblock_read_count is only applicable for tab

Starting 10gR2, db_file_multiblock_read_count is being set automatically depend

March 20th, 2007 § 2 Comments

Database Name - Name of the database

File Name - Name of the datafile

Filename - Name of the file(s)

Version number of core library components in the Oracle Server

QUERY_REWRITE_INTEGRITY determines the degree to which Oracle must enforce query

Vous aimerez peut-être aussi