欧美激情性爽国产精品17p,99成人在线,国产有码在线一区二区视频

Neil's NoteBook — Thu, 11 Nov 2010 03:03:00 GMT

如何才能优化oracle的内存占用情况呢�Q��ؓ了开发的方便�Q�想减少oracle�q�x��占用的内存。下面就为�?zh��n)�介绍一个通过调整oracle内存参数实现减少内存占用的方法，供�?zh��n)�参考学习�?/p>

解决�Ҏ(gu��)��Q?/p>

sqlplus “/ as sysdba"

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

然后��M��的oracle安装目录

找一个init数据库名.ora�q�样一个文�?/p>

把几个oracle内存参数改小�?/p>

一�?G的内存是如下配置的：

*.sga_max_size=712M

*.large_pool_size=8M

*.shared_pool_size=250M

*.sort_area_size=0.5M

*.db_cache_size=350M

然后shutdown数据�?/p>

shutdown immediate;

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

startup;

然后启动�Q�就可以了�?/p>

以上��是调整oracle内存参数�Q�减��数据库内存占用的方法介�l��?/p>

Neil's NoteBook 2010-11-11 11:03 发表评论

oracle 递归查询

Neil's NoteBook — Tue, 19 Oct 2010 02:19:00 GMT

1. 通过子节点向根节点追朔，语法�Q?br /> select * from da_tree start with id='195' connect by prior parentid=id;
2. 通过根节炚w��历子节点�Q�语法：
select * from da_tree start with parentid='21' connect by prior id=parentid;

oracle中的select语句可以用START WITH...CONNECT BY PRIOR子句实现递归查询�Q�connect by 是结构化查询中用到的�Q�其基本语法是：

Java代码

select * from tablename start with cond1 connect by cond2 where cond3;

��单说来是��一个树状结构存储在一张表里，比如一个表中存在两个字�D?

id,parentid那么通过表示每一条记录的parent是谁�Q�就可以形成一个树状结构�?/p>

用上�q�语法的查询可以取得�q�棵树的所有记录�?/p>

Neil's NoteBook 2010-10-19 10:19 发表评论

Windows Vista下安装ORACLE10G需注意事项

Neil's NoteBook — Tue, 08 Sep 2009 03:39:00 GMT

首先、确保你有该文�g夹的完全控制权。（修改�Q�文件夹点右�?nbsp;属�?〉安�?〉高�U?〉所有�?�?/font>改�ؓ自己。接着�~�辑自己的权限�ؓ完全控制�Q?br style="word-wrap: break-word; line-height: normal; " /> 其次、将setup.exe的兼�Ҏ(gu��)��改�?font color="sandybrown" style="word-wrap: break-word; line-height: normal; ">windows server 2003(server pack 1)�?/font>��是右键属�?〉兼�Ҏ(gu��)�?〉兼�Ҏ(gu��)��?/font>中�?br style="word-wrap: break-word; line-height: normal; " /> 接着、右键，以管理员�w�䆾�q�行�?br style="word-wrap: break-word; line-height: normal; " /> 最后、会出现兼容性问题的提示框。选择�q�行�E�序�?/span>

Neil's NoteBook 2009-09-08 11:39 发表评论

Oracle - Rebuild The Temporary Tablespace

Neil's NoteBook — Thu, 12 Mar 2009 09:15:00 GMT

create temporary tablespace TEMP2 TEMPFILE '/home2/oracle/oradata/sysmon/temp02.dbf' SIZE 512M REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED; --创徏中�{临时表空�?/div>

alter database default temporary tablespace temp2; --改变�~�省临时表空�?为刚刚创建的��C��(f��)时表�I�间temp2

drop tablespace temp including contents and datafiles;--删除原来临时表空�?/div>

create temporary tablespace TEMP TEMPFILE '/home2/oracle/oradata/sysmon/temp01.dbf' SIZE 512M REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED; --重新创徏临时表空�?/div>

alter database default temporary tablespace temp; --重置�~�省临时表空间�ؓ新徏的temp表空�?/div>

drop tablespace temp2 including contents and datafiles;--删除中�{用��(f��)时表�I�间

Neil's NoteBook 2009-03-12 17:15 发表评论

Index Skip Scanning

Neil's NoteBook — Wed, 21 Jan 2009 07:22:00 GMT

In previous releases a composite index could only be used if the first column, the leading edge, of the index was referenced in the WHERE clause of a statement. In Oracle9i this restriction is removed because the optimizer can perform skip scans to retrieve rowids for values that do not use the prefix.

How It Works
Advantages
Example

How It Works

Rather than restricting the search path using a predicate from the statement, Skip Scans are initiated by probing the index for distinct values of the prefix column. Each of these distinct values is then used as a starting point for a regular index search. The result is several separate searches of a single index that, when combined, eliminate the affect of the prefix column. Essentially, the index has been searched from the second level down.

The optimizer uses statistics to decide if a skip scan would be more efficient than a full table scan.

Advantages

This approach is advantageous because:

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

First, create and populate a test table with a concatenated index.

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);

Next, run a query that hits the leading edge of the index. Notice the range scan on the index.

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 |

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

Next, run a query that does not hit the leading edge of the index. Notice the index skip scan on the index.

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 |

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

Finally, clean up the test table.

DROP TABLE test_objects;

For more information see:

Index Skip Scans

Hope this helps. Regards Tim...

原文地址�Q?http://oracle-base.com/articles/9i/IndexSkipScanning.php#HowItWorks

Neil's NoteBook 2009-01-21 15:22 发表评论

Oracle Update Join Syntax

Neil's NoteBook — Tue, 20 Jan 2009 07:14:00 GMT

update
(
select a.* from da_page a,da_jbxx b, da_pic c
where a.da_id=b.id
and a.pic_id=c.id
and a.ztdm >= '020'
and a.ztdm < '060'
and (a.shbz='0' or a.shbz='R')
and a.jsbz='N'
and b.swjg_dm like '14201%'
)
set jsbz='Y',shr_dm='14201000087'
where 1=1 and rownum <= '10'

Neil's NoteBook 2009-01-20 15:14 发表评论

Cost Control: Inside the Oracle Optimizer

Neil's NoteBook — Mon, 19 Jan 2009 09:11:00 GMT

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

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.

As a review, the CBO gathers information from many sources, and he has the lofty goal of using DBA-provided metadata to always make the "best" execution plan decision:

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.

原文地址�Q?http://www.dba-oracle.com/art_otn_cbo_p2.htm

Neil's NoteBook 2009-01-19 17:11 发表评论

Cost Based Optimizer (CBO) and Database Statistics

Neil's NoteBook — Mon, 19 Jan 2009 08:00:00 GMT

Whenever a valid SQL statement is processed Oracle has to decide how to retrieve the necessary data. This decision can be made using one of two methods:

Rule Based Optimizer (RBO) - This method is used if the server has no internal statistics relating to the objects referenced by the statement. This method is no longer favoured by Oracle and will be desupported in future releases.
Cost Based Optimizer (CBO) - This method is used if internal statistics are present. The CBO checks several possible execution plans and selects the one with the lowest cost, where cost relates to system resources.

If new objects are created, or the amount of data in the database changes the statistics will no longer represent the real state of the database so the CBO decision process may be seriously impaired. The mechanisms and issues relating to maintenance of internal statistics are explained below:

Analyze Statement
DBMS_UTILITY
DBMS_STATS
Scheduling Stats
Transfering Stats
Issues

Analyze Statement

The ANALYZE statement can be used to gather statistics for a specific table, index or cluster. The statistics can be computed exactly, or estimated based on a specific number of rows, or a percentage of rows:

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

The DBMS_UTILITY package can be used to gather statistics for a whole schema or database. Both methods follow the same format as the analyze statement:

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

The DBMS_STATS package was introduced in Oracle 8i and is Oracles preferred method of gathering object statistics. Oracle list a number of benefits to using it including parallel execution, long term storage of statistics and transfer of statistics between servers. Once again, it follows a similar format to the other methods:

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);

This package also gives you the ability to delete statistics:

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

Scheduling the gathering of statistics using DBMS_Job is the easiest way to make sure they are always up to date:

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;

/

The above code sets up a job to gather statistics for SCOTT for the current time every day. You can list the current jobs on the server using the DBS_JOBS and DBA_JOBS_RUNNING views.

Existing jobs can be removed using:

EXEC DBMS_JOB.remove(X);

COMMIT;

Where 'X' is the number of the job to be removed.

Transfering Stats

It is possible to transfer statistics between servers allowing consistent execution plans between servers with varying amounts of data. First the statistics must be collected into a statistics table. In the following examples the statistics for the APPSCHEMA user are collected into a new table, STATS_TABLE, which is owned by DBASCHEMA:

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

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

This table can then be transfered to another server using your preferred method (Export/Import, SQLPlus Copy etc.) and the stats imported into the data dictionary as follows:

  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.

For more information see:

Refreshing Stale Statistics
DBMS_STATS
DBMS_UTILITY
ANALYZE

Hope this helps. Regards Tim...

原文地址�Q?http://www.oracle-base.com/articles/8i/CostBasedOptimizerAndDatabaseStatistics.php#AnalyzeStatement

Neil's NoteBook 2009-01-19 16:00 发表评论

Neil's NoteBook — Fri, 16 Jan 2009 08:46:00 GMT

1\ 创徏一个专用表保存各表的统计信息：
exec dbms_stats.create_stat_table(''ks38'',''fys'');

2\ ��各表的�l�计信息导入到ks38.fys表中�Q?br /> exec dbms_stats.export_table_stats(''ks38'',''tcl_cust_base_info'',null,''fys'');
---可以创徏不是登陆用户下的表；如用system登陆�Q�可以创��?#8216;ks38''用户�?br />
或将指定schema的统计信息导入到ks38.fys表中
exec dbms_stats.export_schema_stats(''ks38'',''fys'');

注：
若将整个数据库的�l�计信息导出到某个表必须按以下方式做�Q?br /> 1�Q�用SYSDBA角色的用��L��陆（如system)
2) exec dbms_stat.create_stat_table(''system'',''tbl_name''); ----��C��Q�此处创建的表必��L��登陆用户下的表�?
3) exec dbms_stat.export_database_stats(''tbl_name'')

****
导出表状态、SCHEMA�l�计信息�Q�保存导��Z��息的表的SCHEMA可以和登陆用户名不一��_��另外导入�l�计信息的表和原表尽可能
是同一schema下的
导出整个数据库统计信息，保存导出信息的表的SCHEMA必须和登陆用户名一��_��必须是DBA角色�?br />
3\ 查看�l�计信息是否导入�Q?br /> select * from ks38.fys;

4\ 删除某张表的�l�计信息�Q?br /> exec dbms_stats.delete_table_stats(''ks38'',''tcl_cust_base_info'');

5\ 查看�l�计信息是否被删除：
select table_name ,to_char(LAST_ANALYZED,''yyyymmdd hh24:mi:ss'')
from ALL_tables where lower(table_name) LIKE ''tcl_cust_%_info%'';

6\ 导入先前导出的统计信息：
exec dbms_stats.import_table_stats(''ks38'',''tcl_cust_base_info'',''fys'');
注意�Q�tcl_cust_base_info和fys都是�?#8217;ks38''用户下的表�?br />
原文地址�Q?http://database.e800.com.cn/articles/2007/819/1187467720638726675_1.html

Neil's NoteBook 2009-01-16 16:46 发表评论

分析用户所有表之后

Neil's NoteBook — Fri, 16 Jan 2009 08:23:00 GMT

随着Oracle对CBO的进一步增强和改进, 对表�q�行分析已经成�ؓ一�U�常用的调优的手�D? 当发现某个表的相关SQL语句的执行计划有问题�? 首先会想是不是统计信息过旧的问题, 如果的确是过�? 则对�q�个表进行分�? 以让Oracle重新选择准确的最优执行计�? 以达到调优的目标. 用不合适的方式对表�q�分�? 则会造成十分严重的后�? 如对一个用户下的所有表�q�行分析, 或一下子分析多个�? 看到�|�友�?a >一��脓(chu��ng)�?/a>, 让我惌��v二年多前帮别人处理过的一个案�? 有位DBA�Ҏ(gu��)��用户下的所有表�q�行了分�?

基本情况�? IBM P570, 16CPU, 32GB内存, 24GB的SGA, 支持不了一�?0G�?i数据�?OLTP�c�d��), 二百个以内的会话. 在分析之前CPU利用率是50-70%左右, 在分析后则一直是100%. 面��(f��)�q�样的情况后, �׃��没有做统计信�?Statistics)的备�? 因此无法恢复以前的情�? 首先做的是删除所有非分区表的�l�计信息, 对分��做更�_��的统计信息分�? 使之�q�行于RULE方式, 情况�E�有好�{, 但用戯��是不能接�? �怿�Oracle的CBO没有那么�? 因此性能问题的关键�ƈ不在于统计信息了. 在处理了以下几个问题之后, 成功地降底了CPU的利用率.

1, 发现�J�烦�?strong>�q�行�q�程, 发现一个几有几十MB大小的表, 它的�q�行度不�?, 因此��D��了这个表上的一个执行比较繁烦SQL采用了�ƈ行处�? ��ƈ行度�Ҏ(gu��)��1�? CPU利用率降低了20%, 基本上恢复到了分析前的水�?

2, 发现一个后台发��打印程序的SQL有太多的逻辑�? �?strong>发票打印模式�q�行分析�? ��执行繁率从�?0�U�执行一�ơ降底到1分钟执行一��? 因�ؓ从售货台到打印发��的地方取发��需要走1分钟左右. 再检查其SQL, 发现其中的日期条仉��认是两年, 也就是要查最�q�两�q�的销售记�? 再找出没有打印过的记录进行处�? 通过询问销售�h员有没有��Z��来要求打��C��周以前的发票, 当然是很��的�? 后来��这个默认的日期条�g�Ҏ(gu��)��了最�q�一个月. 做了�q�个改动�? �pȝ��的CPU利用率下降到�?0%.

3, 接下来处理了一个库存查询有关的SQL, 对这个SQL本��n没有作�Q何修�? 因�ؓ用户可以自定义条�?动态构造WHERE条�g)�q�行查询, 发现很多用户只选了最��的条�g�q�行�q��o, ��D��了这个SQL�q�行效率极低, 解决办法��是培训前台用户, 让他们��用这个功能时, ��可能地提供比较准确�?strong>查询条�g. �q�样一�? CPU利用率下降到�?5%左右.

4, 调整了一些SQL�? 新的SQL又出��C��, �q�一�ơ的问题�? 看这个SQL的执行计�? 居然用了INDEX合�ƈ(Combine), 在where条�g中用��C��两个�? 开发�h员在�q�两个列上分别徏了烦�? 但从单个列的角度来看, 效率不高, 但一�l�合效率则很�? 因此�?strong>复合索引解决此事. CPU利用率再�ơ小�?%.

5, 后面又调了几个SQL, �q�次�?strong>创徏了几个新的烦�?/strong>, CPU的利用率已经下降��C��20-25%, 目标完成.

��d��来说, 分析表从来都不是优先考虑的调优手�D? 从个��度来�? 只有发现Oracle在某个表上选择了错误的执行计划�? 才会对单个表�q�行分析(分析之前先做备䆾, 除非很确�?, 然后观察, 再分析下一个表.

原文地址�Q?nbsp;http://www.anysql.net/dba/after_analyze_whole_schema.html

Neil's NoteBook 2009-01-16 16:23 发表评论