听风细雨 – 大型网站运维

spotlight on oracle试用 (转)

spotlight on oracle试用

（1）安装

首先在PC上安装Oracle客户端。

我的选择是：Oracle9i Management and Integration 9.0.1.0.1

[描述是安装Management Server，管理工具，Oracle Internet Directory, oracle Integration Server, 网络服务，实用程序和基本的客户机软件]

再次选择：自定义

再次选择：安装Oracle Net Service 9.0.1.1.1中的Oracle Net Listener 9.0.1.1.1

然后结束安装

（2）配置

安装完成之后，有SQL Plus,有Network Configuration Assistant, Net Manager

可以通过Network Configuration Assistant配置[本地网络服务名

或者通过Net Manager的[本地]-[服务命名]添加[服务名],然后连接到Oracle数据库.

（3）测试

通过SQL Plus和第二步配置的服务名,连接到数据库服务器.

测试使用正常.

（4）安装Spotlight on oracle程序

（5）配置连接到Oracle数据库服务器

在主界面中选择[Connect Manager]

再次选择[New Connection]

启一个名字

在[connection string]处选择第二步配置的服务名,输入数据库的用户名和密码.

在[Monitor OS]处输入OS的IP地址,OS的用户名和密码.

（6）启动

在添加好的[连接]上选择[连接]

数据库的性能图表就显示了出来.

（7）性能参数

在性能的全体图上,非常形象的展示了数据库的整体处理过程的监控

客户端 服务进程（前台进程） （系统全局内存区） （后台进程） 物理存储

Sessions <–> Server Process <————————————————–> Storage

用户(活动用户) PGA SGA Backgroup Proecess

Dedicated <—-> Buffer Cache(Hit Ratio) <–> DBWR1 <—-> DB Files

Shared (Keep Pool,Recycle Pool)

Dispathers Redo Buffer <–> LGWR1 <—-> Redo Logs

Parallel Query Shared Pool(Uesed)

JOB Queue Java Pool

Large Pool ARCH1 <—-> Archive Log[

[通讯]

在客户端和服务前台进程之间

(1) < SQL*Net Send(KB/S): The rate at which data is being transferred from the server across the SQL*Net interface

(2) > SQL*Net Received(KB/S): The rate at which data is being transferred to the server, across the SQL*Net interface.

在服务前台进程和SGA之间

(3) < Logic reads/s (blks/s): The rate at which blocks are read from the SGA by all server processes.

(4) > Block changes/s (changes/s): The rate at which changes are made to blocks in the SGA by all server processes. The Lock Wait alarm becomes current on this component if up&#100;ates are being blocked by locks.

(5) > Redo Buffer Entries/s (Entries/s): The rate of redo buffer entries made by all server processes.

(6) > Parse Requests/s (Requests/s): The rate of SQL parse requests per second by all server processes. The Parse ratio alarm becomes current if the ratio of parse requests to execute requests exceeds a threshold

(7) > SQL execution rate (Executations/s): The number of SQL execution requests per second by all server processes.

服务后台进程在SGA和物理存储之间

(8) > Physical Writes/s (blks/s): The rate at which modified blocks are written from the SGA to disk by the DBWR processes.

(9) > Redo Writes/s (blks/s): The rate at which redo log entries are written to the redo log files by the LGWR processes.

在物理存储和服务器前台进程之间

(10) < Physical Reads/s (blks/s): The rate at which blocks are read from disk by all server processes. The Datafile read time alarm becomes active if the average I/O time for these reads exceed a threshold.

[名词]

(1)Total PGA currently in use

The total amount of PGA (Program Global Area) currently in use by all active sessions.

For versions of o&#114;acle up to and including o&#114;acle 8i, it is sum of PGA used in all active sessions. From o&#114;acle 9i onwards, this value represents the &#34;total PGA inuse&#34; statistic in V$PGASTAT.

(2) Dedicated servers

Dedicated server processes that perform work on behalf of a single client process. The number of servers varies as users log in and out of the database

(3)Shared Servers

Shared o&#114; multi-threaded servers (MTS) perform work on behalf of more than one client process. The number of shared servers varies depending on load between the values of the configuration parameters MTS_SERVERS/SHARED_SERVERS and MTS_MAX_SERVERS/MAX_SHARED_SERVERS.

If a high proportion of MTS are busy, then the Multi-threaded server alarm becomes active. For advice on how to deal with this alarm, see the help topic Dealing with MTS contention.

(4) Dispatchers

MTS dispatchers coordinate the allocation of shared servers to client tasks.

The number of dispatchers varies depending on the load between the values of the configuration parameters MTS_DISPATCHERS/DISPATCHERS and MTS_MAX_DISPATCHERS/MAX_DISPATCHERS. If a high proportion of MTS dispatchers are busy, then an alarm may become current on this component. For more information about this alarm, see the help topic Dealing with MTS contention.

(5) Parallel Query

Parallel query servers support parallel execution of queries and (in o&#114;acle8) DML statements. The number of servers varies depending on load between the configuration parameters PARALLEL_MIN_SERVERS and PARALLEL_MAX_SERVERS.

(6) Job queue

Job queue server processes are responsible for running PL/SQL commands submitted to the o&#114;acle job queue via the DBMS_JOB package. The number of job queue processes is determined by the configuration parameter JOB_QUEUE_PROCESSES. If a high proportion of job queue servers become busy, then the Job processes busy alarm becomes current on this component.

(7) Buffer cache Hit Ratio

Buffer Cache Hit Ratio is the percentage of logical reads against total reads. It is the performance indication of the efficiency of the Buffer Cache.

A number of alarms may become current on this component. They include the Buffer Cache Hit Ratio alarm, Cache Buffer LRU Chains Latch alarm, Cache Buffer Chain Latch alarm and the Buffer Busy Wait alarm.

(8) Buffer cache

In o&#114;der to avoid a disk I/O, the buffer cache is used to cache frequently-accessed data blocks that may subsequently be required.

In o&#114;acle versions before o&#114;acle9i, the size of the buffer cache is controlled by the parameter DB_BLOCK_BUFFERS. In later versions, the relevant parameter is DB_n K_CACHE_SIZE.

(9) Keep pool

The Keep Pool keeps objects inside Buffer Cache, without be aged out. The size of Keep Pool is controlled by parameter BUFFER_POOL_KEEP pre 9i and DB_KEEP_CACHE_SIZE since 9i.

(10) Recycle pool

The Recycle pool ages out objects inside it quickly. The size of Recycle pool is controlled by parameter BUFFER_POOL_RECYCLE in o&#114;acle versions before o&#114;acle 9i and DB_RECYCLE_CACHE_SZIE since 9i.

(11) Redo Buffer

The redo buffer contains redo entries that must eventually be written to the redo log.

Alarms can become current if processes spend time waiting for space in the redo buffer (Log buffer space wait alarm), o&#114; for redo buffer latches (Redo allocation and copy latch alarms).

(12) Shared Pool

The shared pool caches SQL statements, PL/SQL programs, object definitions, and session memory for MTS sessions.

A Spotlight user with Alt&#101;r SYSTEM privileges can flush data manually from the shared pool. To do so, right-click on the Shared Pool o&#114; Shared Pool Used component and choose Flush from the shortcut menu. (This option exists only for o&#114;acle versions wh&#101;re manual flushing is supported.)

Note: Flushing the shared pool may adversely affect the performance of the database in the short term.

(13) Java pool

The Java pool caches class definition, Java methods, and Java objects. The size of the Java pool is controlled by the JAVA_POOL_SIZE paramater.

(14) Large pool

The Large pool shows the size of the large pool allocation heap. It is used in MTS for session memory. It can be used by parallel execution and backup processes. The size of the large pool is controlled by the LARGE_POOL_SIZE parameter.

(15) Database writer

The DBWR writes the buffer cache blocks from SGA to data files on hard disks.

The number of DBWR processes is determined by the parameter DB_WRITERS (Oracle7) o&#114; DB_WRITER_PROCESSES (Oracle8 and o&#114;acle8i). This process may display an alarm if it is determined that the DBWR process is causing delays to other processes. The possible alarms are the Free Buffer Waits alarm and the Write Complete Wait alarm.

(16) Log writer (LGWR)

The Log writer writes the redo buffer blocks from SGA to redo log files on the hard disk.

The number of LGWR processes is set at 1 in o&#114;acle 7. It may be configured in o&#114;acle 8 (but not o&#114;acle 8i) by using the LGWR_IO_SLAVES parameter. An alarm can become current on this process if log switch waits occur (Log Switch Time alarm), o&#114; if the average redo I/O time exceeds a threshold (Average Redo Write Time alarm).

statspack报告数据结果解释

本人将最近在学习性能调优时，所用笔记总结如下，欢迎批评指正

本文将不断更新，欢迎补充。（所列数据仅用于便于说明，没有实

际意义）

一、statspack 输出结果中必须查看的十项内容

1、负载间档(Load profile)

2、实例效率点击率(Instance efficiency hit ratios)

3、首要的5个等待事件(Top 5 wait events)

4、等待事件(Wait events)

5、闩锁等待

6、首要的SQL(Top sql)

7、实例活动(Instance activity)

8、文件I/O(File I/O)

9、内存分配(Memory allocation)

10、缓冲区等待(Buffer waits)

二、输出结果解释

1、报表头信息

数据库实例相关信息，包括数据库名称、ID、版本号及主机等信息

2、负载间档

该部分提供每秒和每个事物的统计信息，是监控系统吞吐量和负载变化的重要部分

说明:

Redo size:每秒产生的日志大小(单位字节)，可标志数据库任务的繁重与否

Logical reads:平决每秒产生的逻辑读，单位是block

block changes:每秒block变化数量，数据库事物带来改变的块数量

Physical reads:平均每秒数据库从磁盘读取的block数

Physical writes:平均每秒数据库写磁盘的block数

User calls:每秒用户call次数

Parses:每秒解析次数，近似反应每秒语句的执行次数

软解析每秒超过300次意味着你的&#34;应用程序&#34;效

率不高，没有使用soft soft parse，调整session_cursor_cache

Hard parses:每秒产生的硬解析次数

Sorts:每秒产生的排序次数

Executes:每秒执行次数

Transactions:每秒产生的事务数，反映数据库任务繁重与否

3、实例命中率

该部分可以提前找出ORACLE潜在将要发生的性能问题，很重要

说明:

Buffer Nowait %:在缓冲区中获取Buffer的未等待比率

Redo NoWait %:在Redo缓冲区获取Buffer的未等待比率

Buffer Hit %:数据块在数据缓冲区中得命中率，通常应在90%以上，否则，需要调整

In-memory Sort %:在内存中的排序率

Library Hit %:主要代表sql在共享区的命中率，通常在95%以上，否，需要要考虑加

大共享池，绑定变量，修改cursor_sharing等参数。

Soft Parse %:近似看作sql在共享区的命中率，小于<95%,需要考虑到绑定，如果低于80%，

那么就可能sql基本没有被重用

Execute to Parse %:sql语句解析后被重复执行的次数，如果过低，可以考虑设置

session_cached_cursors参数

Parse CPU to Parse Elapsd %:解析实际运行事件/(解析实际运行时间+解析中等待资源时间)

越高越好

% Non-Parse CPU:查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过多。

Shared Pool相关统计数据

Memory Usage %:共享池内存使用率，应该稳定在75%-90%间，太小浪费内存，太大则内存不足。

% SQL with executions>1:执行次数大于1的sql比率，若太小可能是没有使用bind variables。

% Memory for SQL w/exec>1:也即是memory for sql with execution > 1:执行次数大于1的sql

消耗内存/所有sql消耗的内存

4、首要等待事件

常见等待事件说明:

o&#114;acle等待事件是衡量oracle运行状况的重要依据及指示，主要有空闲等待事件和非空闲等待事件

；空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，

非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。

邮政电子汇兑系统的ORACLE数据库优化策略

一、引言

　　2001年7月1日，中国邮政面向社会开放了24小时现金到现金的电子汇兑业务，覆盖了全国31个省、两千多个市县、一万多个营业网点，取得了较好的经济效益，目前日均交易量已达120万笔。但随着业务的发展，交易量的增加，电子汇兑系统也面临着严重的性能考验。

　　本文根据本人在电子汇兑系统优化工作过程中学习、研究、总结的实际经验，阐述了ORACLE数据库优化的一些有效的策略，相信这些策略对于使用ORACLE数据库的其他金融系统也具有一定的借鉴意义。

二、邮政电子汇兑系统概述

　　电子汇兑系统是邮政综合计算机网上承载的应用系统之一，主机设备采用惠普、IBM和康柏三种类型的服务器集群和磁盘阵列系统，操作系统采用对应于相应主机的HP Unix、IBM AIX和康柏的Digital Unix，数据库软件采用甲骨文公司的ORACLE版本8，中间件采用BEA公司的Tuxedo。

　　电子汇兑系统在软件结构上分为国家局汇兑中心系统、省局汇兑中心系统以及市县网点前端系统三级。

　　国家局汇兑中心系统是跨省交易的交换中心，负责省局汇兑中心系统之间的信息交换和资金结算；省局汇兑中心系统是汇兑业务的处理中心，负责处理全省的汇兑业务，集中存储全省的汇兑业务数据；市县网点前端系统是省局汇兑中心系统的客户端, 负责前台柜面操作的控制处理。

　　国家局汇兑中心系统与省局汇兑中心系统之间采用批量文件的交换方式；省局汇兑中心系统与市县网点前端系统之间采用联机交易处理（OLTP）方式。

三、遇到的问题

　　在电子汇兑交易量日益增大的情况下，电子汇兑系统出现了一些性能问题，主要表现为OLTP处理能力不理想，经常出现联机交易处理时间长，交易大量排队的现象。通过使用操作系统工具进行分析，发现主机的CPU和内存等硬件资源在业务高峰时并没有达到上限，因此电子汇兑系统的硬件资源并没有成为瓶颈，问题应该是出现在应用系统对数据库的访问效率上，优化ORACLE数据库的性能是解决问题的关键。

四、ORACLE数据库的优化策略

　　为了保证ORACLE数据库运行在最佳的性能状态下，在应用系统开发之前就应该充分考虑数据库的优化策略。优化策略一般包括针对数据库的应用设计优化、数据库参数优化、I/O优化和操作系统参数优化等几个方面。其中应用设计的优化工作应该是在应用系统开发之前完成的，其他几个方面的优化工作主要是在应用系统的运行过程中不断地进行的。

　　由于电子汇兑省中心系统采用OLTP模式，对系统性能的要求相对较高，因此，优化工作的重点放在省中心。

1．针对数据库的应用设计优化

　　对于象电子汇兑这样的面向社会公众开放服务的金融计算机系统，在保证数据正确、安全地处理的前提下，获得最快的面对客户的业务处理速度应该是优化工作所追求的最终目标，试想，为了办理一笔汇款业务，客户要在柜台前等待20分钟，这样的系统，还会有人使用吗？

　　在很大程度上，影响数据库请求的处理速度的原因是数据库资源的访问冲突，由于数据库的资源和吞吐量总是有限的，所以，应用设计优化的主要目标是减少冲突。

　　应用设计的优化工作主要包括软件架构的优化、数据库设计的优化和程序设计的优化三个方面。

　1．1软件架构优化

　　在电子汇兑这样的金融系统中，为了保证对外营业期间联机交易能够得到最快的处理，用于满足内部管理需要的功能的处理应放在次要的位置（如历史数据查询和产生报表），限制这部分处理在营业期间对数据库资源的占用，尽量避免与联机事务的处理发生资源上的冲突，优先满足对响应时间要求高的联机交易的需要。

　　查询/报表这部分处理通常时间较长，数据库资源占用也较多，应考虑和联机事务处理分离。报表应尽量放入晚间的批处理作业中处理、营业期间大的联机查询事务应尽可能减少，并且要限制查询范围和查询条件的随意性，复杂的历史数据查询可考虑放在主机以外的设备上进行。

　　联机事务处理的流程也应尽可能简化、数据库操作尽可能少，一些不必须的处理可以放到批处理作业中，以缩短联机交易的处理时间。

　　另外，可以通过中间件的优先级设置机制限制系统中对实时性要求不高的辅助功能的活动（比如电子汇兑系统中的清分功能），以保障联机交易的响应时间。

　1．2数据库设计优化

　　（1）合理设计数据库表，避免表与表之间过多的关联，因为查询会迫使这些表连在一起，如果在这些表中包含大表的时候，整个查询的性能会受到很大影响。

　　（2）合理设计数据库表的层次，避免各子系统和功能模块对数据库表的访问过于集中，尤其是在业务繁忙的时段，因为这样会导致数据库资源的激烈竞争，增加数据库的用户响应时间。在电子汇兑这样的金融系统中，用来存放各种交易数据的表往往非常大，如汇票表、兑付表等，并且是日益增长的，而这些大表中的数据又是系统中各子系统和功能模块都需要的，可以根据各个功能对数据的需求量设计一些中间表，接口表，避免对数据库的大量操作都集中在几个大表上。

　　（3）为了减小联机事务访问的数据量，可以根据业务数据的生命周期，对不同阶段的数据存放在不同的数据库表中，以减少单个表的数据量，从而降低资源的开销。比如可以将交易数据表分为当前表和历史表，联机事务主要对当前表进行访问，在每天日终处理中，将当前表导入历史表。

　　（4）对于很大的表，可以利用数据库的分区机制，分区将表中的行动态地分到一些小表中，可以提高数据维护、事务处理、查询、备份和恢复的性能。

　　（5）索引是建立在表的一列或多列上的辅助对象，有助于快速访问数据表中的数据，但索引由于其内在的结构，存在某些内在的开销，而这些开销有可能会超过进行顺序全表扫描的成本，因此，优化索引是十分必要的。同时，如果在一个表上建立了太多的索引，尤其是大表，当对表进行频繁的插入、删除操作时，为了维护索引所带来的开销是非常大的，因此，不要在一个表上建立太多的索引。另外需要注意，一定要将数据表和相应的索引分开存放在不同的表空间中，以减小I/O的开销。

　1．3程序设计优化

　　在oracle数据库应用中，80％的性能问题是由不良的SQL语句引起的。SQL语言是一种灵活的语言，相同的功能可以使用不同的语句来实现，但是语句的执行效率是很不相同的。应用程序的执行最终将归结为数据库中的SQL语句的执行， SQL语句的执行效率最终决定了ORACLE数据库的性能。因此，优化SQL语句是至关重要的。

　　SQL_TRACE、TKPROF、EXPLAIN PLAN和AUTOTRACE是ORACLE数据库软件自带的应用程序优化工具，程序开发人员要熟练掌握这些工具，运用这些工具对SQL语句进行跟踪和分析，不断进行优化。SQL语句的优化工作非常具体，在这里不做过多的讨论。

2．数据库参数优化

　　数据库参数优化的主要工作是在应用系统运行过程中，根据性能监控的实际情况，不断进行调整以满足应用的需要，使数据库运行在最佳的状态。影响ORACLE数据库性能的参数很多，在这里主要根据电子汇兑系统优化过程中遇到的实际问题，对ORACLE数据库的几个重要组成部分，包括内存参数、回滚段、重做日志文件和临时表空间的优化策略进行分析。

　2．1内存参数的调整

　　内存参数的调整主要是指对ORACLE数据库的系统全局区（SGA）的调整。SGA是分配给ORACLE的所有共享内存结构的集合，主要由三部分构成：共享池、数据库缓冲区和重做日志缓冲区。通过合理调整SGA的各个结构的大小，可以极大地提高系统的性能。

　　SGA的调整，主要的依据是各个内存结构的命中率。较高的命中率说明数据库操作充分利用了内存，效率较高；而较低的命中率则意味着ORACLE必须进行过多的磁盘I/O操作，必然会影响性能。

　　（1）调整共享池区（SPA）

共享池区由两部分构成：库高速缓存（LC）和数据字典高速缓存（DDC）。库高速缓存用来存放用户的SQL语句、过程和函数，数据字典高速缓存用来存放数据库运行中的动态信息。

　　检查库高速缓存的命中率：

　　sel&#101;ct (sum(pins-reloads))/sum(pins) &#34;LIB CACHE&#34; from v$librarycache;

　　如果命中率低于90％，就需要增加共享池的大小。

　　检查数据字典高速缓存的命中率：

　　sel&#101;ct (sum(gets-getmisses))/sum(gets) &#34;ROW CACHE&#34; from v$rowcache;

　　如果命中率低于90％，就需要增加共享池的大小。

　　（2）调整数据库缓冲区

　　ORACLE在运行期间要在数据库缓冲区中读写数据，缓冲区命中表示信息已在内存中，缓冲区失败表示ORACLE必需对磁盘进行操作。

　　检查数据库缓冲区的命中率：

　　sel&#101;ct 1-(phy.value/(cur.value+con.value)) &#34;CACHE HIT RATIO&#34; from v$sysstat cur,v$sysstat con,v$sysstat phy wh&#101;re cur.name=db block gets and con.name=consistent gets and phy.name=physical reads;

　　如果命中率低于90％，就需要增加数据库缓冲区的大小。

　　（3）调整重做日志缓冲区

　　重做日志缓冲区用来缓冲ORACLE要写入重做日志文件中的日志项。

　　检查重做日志缓冲区的使用情况：

　　sel&#101;ct name,value from v$sysstat wh&#101;re name in (redo entries,redo log space requests);

　　计算重做日志缓冲区的申请失败率：requests/entries，如果申请失败率高于1/5000,则说明重做日志缓冲区开设太小，需要扩充。

SQL> sel&#101;ct name,value from v$sysstat wh&#101;re name in (&#39;redo entries&#39;,&#39;redo log space requests&#39;);

NAME VALUE

—————————————————————- ———-

redo entries 83211425

redo log space requests 1806

　　SGA的调整有一点需要注意，SGA并不是越大越好，过大会占用操作系统使用的内存而引起虚拟内存的页面交换，反而会降低系统性能，在一般情况下，SGA占物理内存量的50％为宜，如果不能满足上述指标，则需要扩充物理内存。

　2．2回滚段的调整

　　回滚段是ORACLE数据库中用来存放数据的前映象（即数据修改之前的原值）的数据结构。当一个事务要修改数据时，ORACLE先为该事务分配一个回滚段，将数据的前映象存入回滚段，当程序异常中止或要求撤销时，ORACLE将用回滚段中的前映象恢复数据的原值。

　　回滚段以循环方式分配给进程，所有的事务，无论大小，都竞争使用相同的可用回滚段，除非某个事务指定了使用哪个回滚段。如何配置回滚段以满足系统中各种事务的需要，避免由于回滚段导致性能问题，是数据库优化工作的重要内容。

　（1）调整回滚段的大小

　　当回滚段中的数据量超过了设置的最佳尺寸（OPTIMAL）时，回滚段就会进行扩展，当扩展到回滚段的最大区数（MAXEXTENTS），还不能满足要求，那么，最后进入回滚段的事务就会失败。当回滚段发生扩展后，在一定条件下，会自动回缩到OPTIMAL指定的大小。频繁地扩展和回缩会消耗数据库的资源。

　　观察v$rollstat视图，如果回滚段的发生了多次扩展（EXTENDS），说明回滚段设置小了，应该适当增加回滚段的大小。

　（2）调整回滚段的区（EXTENT）的大小

　　当回滚段的一个区放不下一个事务的回滚段项目时，这个项目就会继续写入下一个区中，一个事务写前映象时跨越回滚段区的边界，这种情况称之为环绕（WRAP）。环绕也会消耗数据库资源。

　　观察v$rollstat视图，如果回滚段发生了多次的环绕（WRAPS）而没有发生扩展（EXTENDS），说明回滚段的区设置小了，应该适当增加回滚段的区的大小。

　　（3）调整回滚段的个数

　　当需要同时使用回滚段的并发事务数超过了所有回滚段能够容纳的事务数总和时，就会发生回滚段的争用，导致事务的等待。

　　检查v$waitstat视图和v$sysstat视图：

　sel&#101;ct class,count from v$waitstat wh&#101;re class in(’undo header’,undo block’);

　sel&#101;ct sum(value) from v$sysstat wh&#101;re name in(‘db block gets’,’consistent gets’)；

　　如果发现任何一个class的count值与sum（value）相比（即等待次数与请求次数相比）超过1％，则应该考虑增加回滚段的个数了。

　　（4）解决“ORA-01555 SNAPSHOT TOO OLD”错误

　　由于ORACLE的“多版本读取一致性”机制，当用户运行一个查询时，ORACLE总是提供在这个查询开始时已提交的数据，用户看不到在这个查询开始之后其他事务对数据的改变。在一个很长的查询过程中，如果其他事务修改了要查询的某个数据块，ORACLE就会到回滚段中寻找该数据的前映象，如果要找的前映象不存在（被其他的回滚段项目覆盖了），就会出现“ORA-01555 SNAPSHOT TOO OLD”错误，导致查询失败，这是ORACLE数据库中常见的问题。

　　在电子汇兑系统的运行过程中，这个问题曾多次出现，解决的办法只能是建立更多的、更大的回滚段，并且不要设置OPTIMAL值，以延迟前映象被覆盖的时间。但这并不能根本地解决问题，还需要在应用程序的设计上找原因。

　　（5）回滚段的配置建议

　　每个回滚段中不要存放超过十个事务，一般四个为宜。

　　对于拥有大量小事务的系统，应该配置数量较多的小回滚段；对于大事务的处理，需要为每个大事务配置一个较大的回滚段。

　　象电子汇兑这样的金融系统，通常是拥有大量的较小的联机事务和少数较大的批处理事务的混合型系统。这种情况需要配置较多的小回滚段供联机事务使用，配置一个或少数几个较大的回滚段供批处理作业使用（在批处理程序中指定）。

　2．3重做日志文件的调整

　　ORACLE数据库中有两个或多个重做日志文件组，日志的功能是记录对数据所做的所有修改。在系统发生故障、阻止数据库将数据写入到数据文件时，重新启动数据库，ORACLE会自动使用日志文件中的信息来恢复数据库的数据文件，保持数据的完整性。

　　（1） 调整日志文件的大小

　　日志文件组是循环写入的，写满一组文件，写下一组文件，最后一组文件写满后，重写第一组文件，如此往复。当发生日志切换时，系统会产生一个检查点，数据库将不一致的数据由内存写到数据文件中。如果日志文件设置过小，切换频繁，检查点就会频繁出现，由于检查点会占用一定的资源，频繁执行就会对性能造成很大影响。一般情况下，日志切换的次数每二十分钟不应多于一次，如果不是这样，就应该增大日志文件。反之，日志文件设置过大，发生故障后，数据库的恢复时间就会很长，这时需要将日志文件调小，或通过设置适当的 LOG_CHECKPOINT_INTERVAL和LOG_CHECKPOINT_TIMEOUT参数值来提高检查点的执行频率。

　　在电子汇兑的数据库日志中经常出现“Checkpoint not complete”的信息。这是什么意思呢？由于日志文件组是循环写入的，当ORACLE准备重写一个日志文件组，但检查点目前尚未完成，这时数据库将暂停，直到检查点完成且ORACLE能够重写日志文件组为止。这是日志频繁切换的表现，这种情况会严重影响数据库的性能，为解决这个问题，应该添加更多的日志文件组或建立更大的日志文件。

　　（2） 保护日志文件的安全

　　日志文件保存了数据库所作的所有数据更改的永久记录，发生故障时，ORACLE要用日志文件进行恢复。如果日志文件损坏，则丢失的数据就无法挽回了！因此，建议在分开的存储设备上建立日志文件的多份镜像，以保证数据的安全。

　　（3）确保日志文件的访问速度

　　当频繁地插入、更新数据（如在电子汇兑业务繁忙时），与之同步的日志文件的写入操作也会十分繁忙，如果存放日志文件的设备访问速度慢，I/O瓶颈就会出现，影响数据库的性能。

　　检查电子汇兑数据库中的等待事件，“log file switch”、“log file sync”、“log file parallel write”等事件经常出现，说明写日志文件存在I/O问题。因此，建议使用更高速的、单独的设备存放日志文件，不要将日志文件与数据库中的数据文件放在相同的设备上。在电子汇兑系统的磁盘阵列上，日志文件是与数据文件一起存放在RAID5磁盘组上的，建议最好使用单独的RAID 1磁盘组来存放日志文件，由于RAID 1不进行校验运算，写入速度要高于RAID 5，并且RAID 1是镜像的，也提供了更高的安全性。

　2．4临时表空间的调整

　　临时表空间是ORACLE用来进行排序操作的表空间，所有用到的排序操作，如建立索引，使用“order by”、“group by”语句以及analyze命令时，都会使用临时表空间。临时表空间的优化主要有以下几个方面。

　　（1）将临时表空间的属性设置为临时（TEMPORARY）

　　ORACLE中的所有表空间默认的属性都是永久的（PERMANENT），包括临时表空间TEMP。当一个表空间的属性设置为临时的，则该表空间只可用于排序操作，不能存放任何对象。将临时表空间设为临时的，由于与永久的表空间的空间管理机制不同，将会提高排序操作的性能。

　　（2）调整临时表空间的大小

　　一方面，在内存允许的条件下，适当增大内存中的排序区的尺寸　（SORT_AREA_SIZE），减少临时表空间中的排序数据量；另一方面，观察v$sort_segment视图，了解数据库中排序操作曾经使用过的最大空间，恰当地调整临时表空间的大小。

　　（3）考虑为每个应用系统建立单独的临时表空间，以减少I/O的消耗。

3.操作系统和I/O优化

　　操作系统的优化主要是合理配置CPU和与之相适应数量的内存、合理分配ORACLE的内存区、为满足ORACLE的需要调整核心参数等内容。操作系统的优化是与操作系统的类型密切相关的，不同厂商的操作系统，如电子汇兑系统使用的HP UNIX、IBM AIX、DIGITAL UNIX，针对ORACLE的调整是不同的，这方面的调整一般要在操作系统厂商的支持下完成。

　　象电子汇兑这样的大型的金融系统，存储设备一般都采用磁盘阵列，磁盘阵列提供了高效的读写性能。对于磁盘阵列的I/O优化，最重要的就是合理选择RAID的类型。最常用的RAID类型有RAID 1、RAID 0＋1/1＋0、RAID5三种。

　　RAID 1（即镜像）适合于对写性能有较高要求的应用；RAID 0＋1/1＋0适合于对读和写都有较高要求的应用；RAID5适合对读性能有较高要求的应用。

　　在上述三种RAID类型中，RAID5的磁盘空间损失最小，而前两种的磁盘利用率只有一半。如何选择需要综合考虑各种因素。

五、结束语

　　ORACLE数据库的性能优化工作是一个技术性强、涉及面广的系统工程，应用系统在运行过程中，会有许多情况发生变化，也会有新的问题出现，这就需要我们根据实际情况，不断地对系统进行适时的调整，解决应用中出现的性能问题。

　　希望本文介绍的这些邮政电子汇兑系统的数据库优化策略，对其他金融系统的ORACLE数据库优化工作，也能起到一定的帮助作用。

Linux系统下Oracle主要监控命令介绍

1．top

top命令可实时地显示Linux系统的进程、CPU、内存、负载等的信息。它是我们了解系统整体状态最好的工具。

top命令的运行状态是一个实时的显示过程，我们可在这个界面监控系统运行情况。我们可通过几个按键来控制top命令，如按q可退出top命令状态，按s可输入信息的更新频率等。这些命令可按h帮助键查询。

2．Ps

ps命令可查询系统的进程状态，常用的命令参数是ps -aux，该命令可显示所有用户的进程，如果进程的命令太长，则显示的进程信息会不全。我们可用ps -auxw命令来加长显示，w参数可多加几个，最多可加三个，以显示更长的进程信息。

3．Kill

kill命令可终止进程，后接进程号即可。

4．Free

free可显示系统的内存使用情况。-b、-k、-m三个参数表示以bytes，kilobytes和megabytes为单位显示内存的使用情况。

5．Vmstat

使用vmstat 2 命令可每隔2秒显示一行系统信息，这些信息包括CPU占用效、内存使用情况和磁盘IO等。通过它我们可实时监控系统的资源使用情况，进行系统优化。

6．sar

sar工具可帮我们收集动态的系统信息，它的参数很丰富，功能强大。sar工具的特点是可通过计数器和计数间隔来定期、定量地输出系统状态信息。

7．watch

watch命令可重复执行某个命令，监控命令的执行状态。下面这个命令可让我们监控Z2.log文件的大小变化。

debian:~# watch -n 3 du /home/Jims/zope/log/Z2.log

-n 3表示每隔3秒执行一次du /home/Jims/zope/log/Z2.log。

8．Sysctl

使用sysctl -a可显示所有运行中的内核参数，用sysctl -w fs.file-max=10240 命令可修改fs.file-max内核参数的值，并使参数马上生效。但重启系统后，参数设置会失效，因为命令行只能修改运行中的内核参数。如果我们要把参数设置固定下来，可把内核参数写入/etc/sysctl.conf文件。该文件的格式如下：

# /etc/sysctl.conf – Configuration file for setting system variables

# See sysctl.conf (5) for information.

# Controls IP packet forwarding

net.ipv4.ip_forward = 0

# Controls source route verification

net.ipv4.conf.default.rp_filter = 1

# Controls the System Request debugging functionality of the kernel

kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.

# Useful for debugging multi-threaded applications.

kernel.core_uses_pid = 1

9．Ulimit

使用ulimit -a可显示系统的资源限制情况。

10．Netstat

netstat -nal可显示所有的网络连接。

11．Pppstat

使用pppstats可得到ppp连接的状态信息