Easy Life,Easy Way

SQL Plus Instant Client 是一个具有SQL Plus 命令行所有功能的独立产品.它不需要安装Oracle客户端,可以直接连接远端的数据库.

1.SQL Plus Instant Client 安装
安装SQL Plus Instant Client, 你需要下面两个包.
可以在OTN下载,也可以从Oracle Client 的安装介质上拷贝相应的文件,拷贝的文件必须是同数据库版本的文件.

(1).SQL*Plus Instant Client package.
(2).Basic OCI Instant Client package, or the lightweight OCI Instant Client package.
Continue reading SQL Plus Instant Client Basis

A doc from Metalink:

Preferred and easiest way of monitoring and setting pga_aggregate_target parameter (PGA) is section ‘PGA Memory Advisory’ in the AWR and Statspack reports.

PGA Memory Advisory

• When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value where Estd PGA Overalloc Count is 0

In this section, you first find the row where field ‘Size Factr’ is 1.00.  The field ‘PGA Target Est(MB)’ of this row will show your current PGA setting – figure 1024 in the above example. Other fields (columns) you will be interested in are: ‘Estd Extra W/A MB Read/ Written to Disk ‘ and ‘Estd PGA Overalloc Count’.

When you go down or up the advisory section from the row with ‘Size Factr’ = 1.00, you get estimations for Disk usage – column ‘Estd Extra W/A MB Read/ Written to Disk ‘ - for bigger or smaller settings of pga_aggregate_target. The less Disk usage figure in this column,  usually the better.

Your first goal is to have such a setting of pga_aggregate_target, that number in the column ‘Estd Extra W/A MB Read/ Written to Disk ‘ does not substantially reduce any more, see figure 28863.55 in the example AWR report.
In other words, further increases of pga_aggregate_target won’t give any more benefit.

Column ‘Estd PGA Overalloc Count’ shows estimations of how many times database would need to request from OS more PGA memory than the amount shown in the ‘PGA Target Est(MB)’ field of the respective row. Ideally this field  should be 0, and that is your equally important second goal.

In many cases  ‘Estd PGA Overalloc Count’ figures reach 0 before  the number in ‘Estd Extra W/A MB Read/ Written to Disk ‘ stabilizes

Question whether increase from the current actual size is possible  for a given database, should be always investigated.  The answer depends on how much of total memory (SGA+PGA) can be allocated for this database on this box, i.e. take into account memory needs of other databases, software and OS residing on the box.

Ref:DOC ID:786554.1

If you want to convert the times (expressed in seconds) back into percentages, then total elapsed time is
e = BUSY_TIME + IDLE_TIME + IOWAIT TIME or
e = SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME since BUSY_TIME = (SYS_TIME+USER_TIME)

e should also be roughly close to elapsed time of report (59.78 min * 60 seconds/min * 8 (NUM_CPUS))

but the report itself takes time to run (actually the snapshots take time as well) and neither the snapshot,

the V$ tables the snapshot is taken from, nor the report itself are AS OF a single consistent point in time.

Anyway at this point you can see, (BUSY_TIME / e) = %busy.
Finally,

This is CPU time Oracle reports it used (though we don’t include time spent in SQL*Net code and maybe not all background

processes may be reporting the CPU time they used). It is expressed in centiseconds rather than seconds so

234,148 / (e * 100) will tell you what percent of the total CPU resources on the machine Oracle was keeping busy.

Actually it’s probably easier to look at DB CPU stat since that is already in seconds.

BUSY_TIME – “DB CPU” is the amount of CPU usage that seems to be because of things mostly happening outside the database.