如何才能优化oracle的内存占用情况呢？为了开发的方便，想减少oracle平时占用的内存。下面就为您介绍一个通过调整oracle内存参数实现减少内存占用的方法，供您参考学习。

解决方法：

sqlplus “/ as sysdba"  

 create pfile='d:/cj.ora' from spfile;  

然后去你的oracle安装目录

找一个init数据库名.ora这样一个文件

把几个oracle内存参数改小点

一个2G的内存是如下配置的：

*.sga_max_size=712M

*.large_pool_size=8M

*.shared_pool_size=250M

*.sort_area_size=0.5M

*.db_cache_size=350M

然后shutdown数据库

shutdown immediate;  

 create spfile from pfile='d:/cj2.ora';  

 startup;  

然后启动，就可以了。

以上就是调整oracle内存参数，减少数据库内存占用的方法介绍。

• How It Works
• Advantages
• Example

How It Works

Advantages

• It reduces the number of indexes needed to support a range of queries. This increases performance by reducing index maintenance and decreases wasted space associated with multiple indexes.
• The prefix column should be the most discriminating and the most widely used in queries. These two conditions do not always go hand in hand which makes the decision difficult. In these situations skip scanning reduces the impact of makeing the "wrong" decision.

Example

CREATE TABLE test_objects AS

SELECT * FROM all_objects;



CREATE INDEX test_objects_i ON test_objects (owner, object_name, subobject_name);



EXEC DBMS_STATS.gather_table_stats(USER, 'TEST_OBJECTS', cascade => TRUE);

SQL> SET AUTOTRACE ON

SQL> SELECT owner, object_name

2  FROM   test_objects

3  WHERE  owner       = 'SYS'

4  AND    object_name = 'DBMS_OUTPUT';



OWNER                          OBJECT_NAME

------------------------------ ------------------------------

SYS                            DBMS_OUTPUT



1 row selected.





Execution Plan

----------------------------------------------------------

Plan hash value: 3650344004



-----------------------------------------------------------------------------------

| Id  | Operation        | Name           | Rows  | Bytes | Cost (%CPU)| Time     |

-----------------------------------------------------------------------------------

|   0 | SELECT STATEMENT |                |     1 |    32 |     2   (0)| 00:00:01 |

|*  1 |  INDEX RANGE SCAN| TEST_OBJECTS_I |     1 |    32 |     2   (0)| 00:00:01 |

-----------------------------------------------------------------------------------

SQL> SET AUTOTRACE ON

SQL> SELECT owner, object_name

2  FROM   test_objects

3  WHERE  object_name = 'DBMS_OUTPUT';



OWNER                          OBJECT_NAME

------------------------------ ------------------------------

PUBLIC                         DBMS_OUTPUT

SYS                            DBMS_OUTPUT



2 rows selected.





Execution Plan

----------------------------------------------------------

Plan hash value: 1293870291



-----------------------------------------------------------------------------------

| Id  | Operation        | Name           | Rows  | Bytes | Cost (%CPU)| Time     |

-----------------------------------------------------------------------------------

|   0 | SELECT STATEMENT |                |     2 |    64 |    14   (0)| 00:00:01 |

|*  1 |  INDEX SKIP SCAN | TEST_OBJECTS_I |     2 |    64 |    14   (0)| 00:00:01 |

-----------------------------------------------------------------------------------

DROP TABLE test_objects;

• Index Skip Scans

PART 2 - CBO Statistics

The most important key to success with the CBO is to carefully define and manage your statistics. In order for the CBO to make an intelligent decision about the best execution plan for your SQL, it must have information about the table and indexes that participate in the query. When the CBO knows the size of the tables and the distribution, cardinality, and selectivity of column values, the CBO can make an informed decision and almost always generates the best execution plan.

Oracle uses data from many sources to make an execution plan

Let's examine the following areas of CBO statistics and see how to gather top-quality statistics for the CBO and how to create an appropriate CBO environment for your database.

Getting top-quality statistics for the CBO. The choices of executions plans made by the CBO are only as good as the statistics available to it. The old-fashioned analyze table and dbms_utility methods for generating CBO statistics are obsolete and somewhat dangerous to SQL performance. As we may know, the CBO uses object statistics to choose the best execution plan for all SQL statements.

The dbms_stats utility does a far better job in estimating statistics, especially for large partitioned tables, and the better statistics result in faster SQL execution plans. Here is a sample execution of dbms_stats with the OPTIONS clause:

exec dbms_stats.gather_schema_stats( - 

ownname          => 'SCOTT', - 

options          => 'GATHER AUTO', - 

estimate_percent => dbms_stats.auto_sample_size, - 

method_opt       => 'for all columns size repeat', - 

degree           => 34 - 

)

Here is another dbms_stats example that creates histograms on all indexes columns:

BEGIN

dbms_stats.gather_schema_stats(

ownname=>'TPCC',

METHOD_OPT=>'FOR ALL INDEXED COLUMNS SIZE SKEWONLY',

CASCADE=>TRUE,

ESTIMATE_PERCENT=>100);

END;

/

There are several values for the OPTIONS parameter that we need to know about:

• GATHER_ reanalyzes the whole schema
   
• GATHER EMPTY_ only analyzes tables that have no existing statistics
   
• GATHER STALE_ only reanalyzes tables with more than 10 percent modifications (inserts, updates,   deletes)
   
• GATHER AUTO_ will reanalyze objects that currently have no statistics and objects with stale statistics.  Using GATHER AUTO is like combining GATHER STALE and GATHER EMPTY.

Note that both GATHER STALE and GATHER AUTO require monitoring. If you issue the ALTER TABLE XXX MONITORING command, Oracle tracks changed tables with the dba_tab_modifications view. Below we see that the exact number of inserts, updates and deletes are tracked since the last analysis of statistics:

SQL> desc dba_tab_modifications;



Name                Type

--------------------------------

TABLE_OWNER         VARCHAR2(30)

TABLE_NAME          VARCHAR2(30)

PARTITION_NAME      VARCHAR2(30)

SUBPARTITION_NAME   VARCHAR2(30)

INSERTS             NUMBER

UPDATES             NUMBER

DELETES             NUMBER

TIMESTAMP           DATE

TRUNCATED           VARCHAR2(3)

The most interesting of these options is the GATHER STALE option. Because all statistics will become stale   quickly in a robust OLTP database, we must remember the rule for GATHER STALE is > 10% row change   (based on num_rows at statistics collection time). Hence, almost every table except read-only tables will be reanalyzed with the GATHER STALE option, making the GATHER STALE option best for systems that are       largely read-only. For example, if only five percent of the database tables get significant updates, then only        five percent of the tables will be reanalyzed with the GATHER STALE option.

Automating sample size with dbms_stats.The better the quality of the statistics, the better the job that the    CBO will do when determining your execution plans. Unfortunately, doing a complete analysis on a large  database could take days, and most shops must sample your database to get CBO statistics. The goal is to take a large enough sample of the database to provide top-quality data for the CBO.

Now that we see how the dbms_stats option works, let's see how to specify an adequate sample size for dbms_stats.

In earlier releases, the DBA had to guess what percentage of the database provided the best sample size and sometimes underanalyzed the schema. Starting with Oracle9i Database, the estimate_percent argument is a great way to allow Oracle's dbms_stats to automatically estimate the "best" percentage of a segment to sample when gathering statistics:

estimate_percent => dbms_stats.auto_sample_size

After collecting automatic sample sizes, you can verify the accuracy of the automatic statistics sampling by    looking at the sample_size column on any of these data dictionary views:

• DBA_ALL_TABLES
• DBA_INDEXES
• DBA_IND_PARTITIONS
• DBA_IND_SUBPARTITIONS
• DBA_OBJECT_TABLES
• DBA_PART_COL_STATISTICS
• DBA_SUBPART_COL_STATISTICS
• DBA_TABLES
• DBA_TAB_COLS
• DBA_TAB_COLUMNS
• DBA_TAB_COL_STATISTICS
• DBA_TAB_PARTITIONS
• DBA_TAB_SUBPARTITIONS

Note that Oracle generally chooses a sample_size from 5 to 20 percent when using automatic sampling, depending on the size of the tables and the distribution of column values. Remember, the better the quality of  your statistics, the better the decision of the CBO.

Update:

In Oracle we now see 11g extended optimizer statistics, an alternative to dynamic_sampling for estimating result set sizes.

Now that we understand the value of CBO statistics, let's look at ways that the CBO statistics are managed in a successful Oracle shop.

The WISE Oracle tool is the easiest way to analyze Oracle performance and WISE allows you to spot hidden performance trends.

原文地址： http://www.dba-oracle.com/art_otn_cbo_p2.htm

• Analyze Statement
• DBMS_UTILITY
• DBMS_STATS
• Scheduling Stats
• Transfering Stats
• Issues

Analyze Statement

ANALYZE TABLE employees COMPUTE STATISTICS;

ANALYZE INDEX employees_pk COMPUTE STATISTICS;



ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE 100 ROWS;

ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE 15 PERCENT;

DBMS_UTILITY

EXEC DBMS_UTILITY.analyze_schema('SCOTT','COMPUTE');

EXEC DBMS_UTILITY.analyze_schema('SCOTT','ESTIMATE', estimate_rows => 100);

EXEC DBMS_UTILITY.analyze_schema('SCOTT','ESTIMATE', estimate_percent => 15);



EXEC DBMS_UTILITY.analyze_database('COMPUTE');

EXEC DBMS_UTILITY.analyze_database('ESTIMATE', estimate_rows => 100);

EXEC DBMS_UTILITY.analyze_database('ESTIMATE', estimate_percent => 15);

DBMS_STATS

EXEC DBMS_STATS.gather_database_stats;

EXEC DBMS_STATS.gather_database_stats(estimate_percent => 15);



EXEC DBMS_STATS.gather_schema_stats('SCOTT');

EXEC DBMS_STATS.gather_schema_stats('SCOTT', estimate_percent => 15);



EXEC DBMS_STATS.gather_table_stats('SCOTT', 'EMPLOYEES');

EXEC DBMS_STATS.gather_table_stats('SCOTT', 'EMPLOYEES', estimate_percent => 15);



EXEC DBMS_STATS.gather_index_stats('SCOTT', 'EMPLOYEES_PK');

EXEC DBMS_STATS.gather_index_stats('SCOTT', 'EMPLOYEES_PK', estimate_percent => 15);

EXEC DBMS_STATS.delete_database_stats;

EXEC DBMS_STATS.delete_schema_stats('SCOTT');

EXEC DBMS_STATS.delete_table_stats('SCOTT', 'EMPLOYEES');

EXEC DBMS_STATS.delete_index_stats('SCOTT', 'EMPLOYEES_PK');

Scheduling Stats

SET SERVEROUTPUT ON

DECLARE

l_job  NUMBER;

BEGIN



DBMS_JOB.submit(l_job,

'BEGIN DBMS_STATS.gather_schema_stats(''SCOTT''); END;',

SYSDATE,

'SYSDATE + 1');

COMMIT;

DBMS_OUTPUT.put_line('Job: ' || l_job);

END;

/

EXEC DBMS_JOB.remove(X);

COMMIT;

Transfering Stats

  SQL> EXEC DBMS_STATS.create_stat_table('DBASCHEMA','STATS_TABLE');

SQL> EXEC DBMS_STATS.export_schema_stats('APPSCHEMA','STATS_TABLE',NULL,'DBASCHEMA');

  SQL> EXEC DBMS_STATS.import_schema_stats('APPSCHEMA','STATS_TABLE',NULL,'DBASCHEMA');

SQL> EXEC DBMS_STATS.drop_stat_table('DBASCHEMA','STATS_TABLE');

Issues

• Exclude dataload tables from your regular stats gathering, unless you know they will be full at the time that stats are gathered.
• I've found gathering stats for the SYS schema can make the system run slower, not faster.
• Gathering statistics can be very resource intensive for the server so avoid peak workload times or gather stale stats only.
• Even if scheduled, it may be necessary to gather fresh statistics after database maintenance or large data loads.

• Refreshing Stale Statistics
• DBMS_STATS
• DBMS_UTILITY
• ANALYZE

    基本情况是, IBM P570, 16CPU, 32GB内存, 24GB的SGA, 支持不了一个50G的9i数据库(OLTP类型), 二百个以内的会话. 在分析之前CPU利用率是50-70%左右, 在分析后则一直是100%. 面临这样的情况后, 由于没有做统计信息(Statistics)的备份, 因此无法恢复以前的情况, 首先做的是删除所有非分区表的统计信息, 对分区表做更精确的统计信息分析, 使之运行于RULE方式, 情况稍有好转, 但用户还是不能接受, 相信Oracle的CBO没有那么差, 因此性能问题的关键并不在于统计信息了. 在处理了以下几个问题之后, 成功地降底了CPU的利用率.

    1, 发现繁烦的并行进程, 发现一个几有几十MB大小的表, 它的并行度不为1, 因此导致了这个表上的一个执行比较繁烦SQL采用了并行处理, 将并行度改成1后, CPU利用率降低了20%, 基本上恢复到了分析前的水准.

    2, 发现一个后台发票打印程序的SQL有太多的逻辑读, 对发票打印模式进行分析后, 建议将执行繁率从每10秒执行一次降底到1分钟执行一次, 因为从售货台到打印发票的地方取发票需要走1分钟左右. 再检查其SQL, 发现其中的日期条件默认是两年, 也就是要查最近两年的销售记录, 再找出没有打印过的记录进行处理, 通过询问销售人员有没有人会来要求打印两周以前的发票, 当然是很少的了, 后来将这个默认的日期条件改成了最近一个月. 做了这个改动后, 系统的CPU利用率下降到了50%.

    3, 接下来处理了一个库存查询有关的SQL, 对这个SQL本身没有作任何修改, 因为用户可以自定义条件(动态构造WHERE条件)进行查询, 发现很多用户只选了最少的条件进行过滤, 导致了这个SQL运行效率极低, 解决办法就是培训前台用户, 让他们使用这个功能时, 尽可能地提供比较准确的查询条件. 这样一来, CPU利用率下降到了35%左右.

    4, 调整了一些SQL后, 新的SQL又出现了, 这一次的问题是, 看这个SQL的执行计划, 居然用了INDEX合并(Combine), 在where条件中用到了两个列, 开发人员在这两个列上分别建了索引, 但从单个列的角度来看, 效率不高, 但一组合效率则很高, 因此用复合索引解决此事. CPU利用率再次小降5%.

    5, 后面又调了几个SQL, 这次是创建了几个新的索引, CPU的利用率已经下降到了20-25%, 目标完成.

    总地来说, 分析表从来都不是优先考虑的调优手段, 从个人角度来看, 只有发现Oracle在某个表上选择了错误的执行计划后, 才会对单个表进行分析(分析之前先做备份, 除非很确定), 然后观察, 再分析下一个表.