February 2010
M T W T F S S
« Jan    
1234567
891011121314
15161718192021
22232425262728

windows 快捷方式 -网上的,收藏之

F1 帮助
F2 改名
F3 搜索
F4 地址
F5 刷新
F6 切换
F10菜单

Continue reading windows 快捷方式 -网上的,收藏之

High-water Mark

High-water Mark

This is a term used with table segments stored in the database. If you envision a table, for example, as a ‘flat’ structure or as a series of blocks laid one after the other in a line from left to right, the high-water mark (HWM) would be the rightmost block that ever contained data, as illustrated in Figure 10-1.

+---- high water mark of newly created table
|
V
+--------------------------------------------------------+
|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

      high water mark after inserting 10,000 rows
                                    |
                                    v
+--------------------------------------------------------+
|x |x |x |x |x |x |x |x |x |x |x |x |  |  |  |  |  |  |  |
|x |x |x |x |x |x |x |x |x |x |x |x |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

      high water mark after inserting 10,000 rows
                                    |
                                    v
+--------------------------------------------------------+
|x |x |x |x |x |x |x |  |  |  |  |  |  |  |  |  |  |  |  |
|x |x |x |x |x |x |x |  |  |  |  |  |  |  |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Figure 10-1. Depiction of an HWM

Figure 10-1 shows that the HWM starts at the first block of a newly created table. As data is placed into the table over time and more blocks get used, the HWM rises. If we delete some (or even all) of the rows in the table, we might have many blocks that no longer contain data, but they are still under the HWM, and they will remain under the HWM until the object is rebuilt, truncated, or shrunk (shrinking of a segment is a new Oracle 10g feature that is supported only if the segment is in an ASSM tablespace).

The HWM is relevant since Oracle will scan all blocks under the HWM, even when they contain no data, during a full scan. This will impact the performance of a full scan¿especially if most of the blocks under the HWM are empty. To see this, just create a table with 1,000,000 rows (or create any table with a large number of rows), and then execute a SELECT COUNT(*) from this table. Now, DELETE every row in it and you will find that the SELECT COUNT(*) takes just as long (or longer, if you need to clean out the block! Refer to the ‘Block Cleanout’ section of Chapter 9) to count 0 rows as it did to count 1,000,000. This is because Oracle is busy reading all of the blocks below the HWM to see if they contain data. You should compare this to what happens if you used TRUNCATE on the table instead of deleting each individual row. TRUNCATE will reset the HWM of a table back to ‘zero’ and will truncate the associated indexes on the table as well. If you plan on deleting every row in a table, TRUNCATE¿if it can be used¿would be the method of choice for this reason.

In an MSSM tablespace, segments have a definite HWM. In an ASSM tablespace, however, there is an HWM and a low HWM. In MSSM, when the HWM is advanced (e.g., as rows are inserted), all of the blocks are formatted and valid, and Oracle can read them safely. With ASSM, however, when the HWM is advanced Oracle doesn¿t format all of the blocks immediately¿they are only formatted and made safe to read upon their first use. So, when full scanning a segment, we have to know if the blocks to be read are ’safe’ or unformatted (meaning they contain nothing of interest and we do not process them). To make it so that not every block in the table need go through this safe/not safe check, Oracle maintains a low HWM and a HWM. Oracle will full scan the table up to the HWM¿and for all of the blocks below the low HWM, it will just read and process them. For blocks between the ‘low HWM’ and the HWM, it must be more careful and refer to the ASSM bitmap information used to manage these blocks in order to see which of them it should read and which it should just ignore.

SQL Plus Instant Client Basis

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

生活成本在不断的增加

今天交房租给房东,房东说要收水费了(以前水费不收)。问为什么?答曰:你老婆来了,用水也多了。
oh,shit.我老婆来了也没多用多少水啊。
估计是看见我买了个洗衣机……
自从来杭州就一直租着这个房子,两年多了,经历了一次房租的涨价,这次又是水费。
看来要考虑换房子了。

How to Read PGA Memory Advisory Section in AWR and Statspack Reports

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
PGA Target Est (MB) Size Factr W/A MB Processed Estd Extra W/A MB Read/ Written to Disk Estd PGA Cache Hit % Estd PGA Overalloc Count
128 0.13 258,572.74 127,776.77 67.00 2,010
256 0.25 258,572.74 31,433.28 89.00 0
512 0.50 258,572.74 29,560.27 90.00 0
768 0.75 258,572.74 28,863.55 90.00 0
1,024 1.00 258,572.74 28,863.55 90.00 0
1,229 1.20 258,572.74 4,643.11 98.00 0
1,434 1.40 258,572.74 4,643.11 98.00 0
1,638 1.60 258,572.74 4,643.11 98.00 0
1,843 1.80 258,572.74 4,643.11 98.00 0
2,048 2.00 258,572.74 4,643.11 98.00 0
3,072 3.00 258,572.74 4,643.11 98.00 0
4,096 4.00 258,572.74 4,643.11 98.00 0
6,144 6.00 258,572.74 4,643.11 98.00 0
8,192 8.00 258,572.74 4,643.11 98.00 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