Oracle Tech Zone

深入SecureFile—新一代LOB揭秘

Romeo — Tue, 18 Jan 2011 14:32:44 +0000

全文PDF版本可以在这里下载，格式排版要容易看一些SecureFile_Internal.pdf。

1. SecureFile LOB的特点

最近张乐亦（Kamus）在gtalk上问了俺一个问题，为啥SecureFile类型的LOB要比以前的LOB性能要好很多，是不是存储结构上发生了什么变化。这两天抽空看了些资料，现在整理出来算是回答他的问题了。

关于11g以前的LOB类型的实现方式可以参考前一段写的一篇博文《CLOB的物理存储结构及语言编码详解》。从11g开始，Oracle提供了一种新的LOB存储方式叫SecureFile，以前旧有的LOB存储方式就叫BasicFile了。Oracle宣称，“SecureFile不仅是新一代 LOB，它们还为 LOB 带来了更多的价值，尤其是以前只能在文件系统领域中获得的特性。SecureFile可以进行加密以确保安全性，可以进行重复消除和压缩以提高存储效率，可以进行缓存（或不进行缓存）以加快访问（或节省缓冲池空间），可以按多个级别记录以减少崩溃后的平均恢复时间。引入 SecureFile 后，您可以在数据库中存储更多的非结构化文档，而不会导致过多的开销，也不会失去 OS 文件系统提供的任何重要功能。”

简单来说就三条：

一、提供了压缩、重复消除、加密等新功能

二、比以前的LOB的性能提高很多

三、易用性（无需设置CHUNK、PCTVERSION、FREELISTS、FREELIST GROUPS、FREEPOOLS参数）

注意：压缩需要Oracle Advanced Compression Option，加密需要Oracle Advanced Security Option，这两个option都是单独购买的，没有包括在Enterprise Edition里面。

2. 使用SecureFile

想要使用SecureFile LOB很简单，只需指定STORE AS SECUREFILE子句就行了（测试环境为11gR2）：

CREATE TABLE tst.t11 (id number,c1 CLOB) LOB (c1) STORE AS SECUREFILE;

Securefile列标明了是否为SecureFile类型的LOB：

SELECT table_name,segment_name,index_name,securefile FROM dba_lobs WHERE table_name='T11';
TABLE_NAME SEGMENT_NAME                   INDEX_NAME                     SECUREFIL
---------- ------------------------------ ------------------------------ ---------
T11        SYS_LOB0000069030C00001$$      SYS_IL0000069030C00001$$       YES

使用Securefile LOB的表也是自动生成LOB segment和LOB index的。但是此时LOB index只有在使用重复消除功能时才会使用，在其他情况下均不会使用。要注意，Securefile LOB只能在ASSM的表空间（自动管理的表空间）里创建，不过既然从9i起ASSM表空间就是默认设置了，一般这里不会有多大问题。还要多说一句，只是要求SecureLOB所在的LOB列数据需要存放在ASSM表空间中，而包含LOB列的那个表，你还是可以放在手动管理的表空间中。

想使用SecureFile LOB，对数据库的参数DB_SECUREFILE设置也有一定的要求：

PERMITTED：数据库的默认参数。指定SecureFile时创建SecureFile类型的LOB；未指定时，或显式指定BasicFile时，创建BasicFile类型的LOB。

FORCE：无论是否指定SecureFile，强制创建SecureFile类型的LOB。在手动管理的表空间上创建LOB时，无论STORAGE子句是否指定SecureFile，均报ORA-43853错。

ALWAYS：无论是否指定SecureFile，强制创建SecureFile类型的LOB。在手动管理的表空间上创建LOB时，若STORAGE子句未显式指定LOB类型，创建为BasicFile类型的LOB；若STORAGE子句显式指定SecureFile类型，则也报ORA-43853错。

NEVER：无论是否指定SecureFile，强制创建BasicFile类型的LOB。指定SecureFile类型特有的功能如压缩，加密，重复消除时，报ORA-43854错。

IGNORE：无论是否指定SecureFile，强制创建BasicFile类型的LOB。忽略SecureFile类型特有的功能，创建BasicFile类型的LOB。

3. BasicFile和SecureFile的架构比较

3.1. 可变Chunk

首先介绍一下SecureFile中的可变Chunk。大家都知道在BasicFile的LOB中，Chunk的大小是一定的，最小跟DB Block的大小一样，最大为32KB，这存在一些问题。比如chunk比LOB的数据小很多的情况下，访问LOB就会产生很多IO，而chunk比LOB的数据大很多的情况下，又会产生对存储空间的浪费。而在SecureFile中，chunk的size是可变的，由Oracle自动动态分配，最小跟DB Block的大小一样，最大为64MB。这样在存储较小的LOB时，使用比较小的chunk；在存储比较大的LOB时，会使用比较大的chunk。注意不是说一个LOB就放在一个chunk里，而是oracle根据LOB data的数据大小会自动决定chunk数和chunk的size，具体可以看下面“SecureFile的物理存储结构”一节的实验结果。

3.2. LOB index

在LOB数据的存储方式上，两种LOB也有很大的区别。关于BasicFile的存储方式，在《CLOB的物理存储结构及语言编码详解》一文中有详细的介绍，大概就是表中的LOB字段只存储LOB locator，指向LOB index，LOB index再指向LOB segment里实际的LOB数据。不难看出，这里增加了一个LOB index的结构，那么不可避免的，LOB index就有可能产生竞争，成为瓶颈。在SecureFile中，LOB index只有在使用重复消除功能时才会使用（关于这个结论的验证方法，在CLOB那篇文章中有记载，这里不再赘述了）。简而言之，SecureFile中只要不使用重复消除功能就没LOB index什么事，自然性能就上去了。

BasicFile	Col1	LOB col	—->	LOB index	—->	LOB data
SecureFile	Col1	LOB col	—————->			LOB data

3.3. 空闲空间搜索

在BasicFile里，关于有空间的使用情况的信息是保存在LOB index和LOB segment里的。在INSERT或UPDATE操作LOB segment时，以下面的顺序来搜索空闲空间：

1. 在LOG segment的管理区搜索空闲空间，如果没有，转下一步

2. 访问LOB index，把可以释放的空间（如已经commit的transaction使用的UNDO）释放掉，并更新索引entry。如果不存在这种可以释放的空间，转下一步

3. 将HWM升高，扩大LOB segment，使用新分配的空间

由此可见，BasicFile的LOB在搜索空闲空间时，可能会去扫描LOB index。因此LOB index的竞争，或者在LOB数据很多的情况下，搜索LOB index的空闲空间这个操作本身都会造成时间上的花费。

对于空闲空间的管理，SecureFile将其放入了shared pool，这比BasicFile空闲空间管理的效率有了质的提高。 Shared Pool里的这个内存结构叫In-memory dispenser，它把空闲空间的信息cache在内存里，因此速度要比访问LOB index快了N个数量级。In-memory dispenser负责接受前台进程对于LOB空间的请求，并进行chunk的分配。

在In-memory dispenser中管理的空闲空间不是全部，而只是一部分而已，它的信息由后台进程SMCO/Wnnn来定期的更新。SMCO/Wnnn监视SecureFile LOB segment的使用情况，根据需要保证空闲空间的供应。注意SMCO/Wnnn也负责普通的ASSM表空间的空间动态分配。

1. SMCO进程（Space Management Coordinator）。负责前瞻式（Proactive）的空间分配，它动态产生slave进程Wnnn来完成实际的工作。

2. Wnnn（SMCO Worker）每10分钟扫描一遍LOB segment的状态，根据需要把空chunk移动到In-memory dispenser中。如果这样空chunk还是不够，则扩大LOB segment。

此时在INSERT或UPDATE操作LOB segment时，以下面的顺序来搜索空闲空间：

1. 前台进程向In-memory dispenser发出需要chunk的请求

2. In-memory dispenser里的chunk信息里如果空chunk数量不足，或者空chunk的size不够时，在LOG segment的管理区搜索空闲空间，将空chunk的信息cache在In-memory dispenser里。如果搜索不到空闲空间，转下一步

3. 将HWM升高，扩大LOB segment，使用新分配的空间

3.4. STORAGE参数

跟BasicFile一样，SecureFile同样也有enable storage in row和disable storage in row的区别，在SecureFile的LOB里默认设置同样也是enable storage in row。LOB控制结构size加上LOB数据size一共未满4000字节时，enable storage in row的情况下就存储在源表的LOB列内，超出时就存放在LOB segment里；而disable storage in row的情况下则无论是否超过4000字节，LOB数据均存放在LOB segment里。

《CLOB的物理存储结构及语言编码详解》一文中提到过，enable storage in row的情况下源表的LOB列最多能存放3964字节；而在DB11gR1的SecureFile LOB中，变成了3740字节；DB11gR2时又变成了3952字节。均为引用的数据，具体区别尚未弄清。个人认为Size的变化都是因为LOB的控制信息发生了细微的变化。注意这里的size都是在未使用重复消除、加密、压缩选项的情况下得出的。

4. SecureFile的物理存储结构

下面就是本文的重头戏了，SecureFile的LOB到底在物理上是怎么存储的。在Table的Segment里的LOB列中，存放着两个layer：Locator Layer（20字节）和Inode Layer。Locator的内容和BasicFile里是一样的，也包括了控制信息和10字节的LOB ID。而Inode Layer包含了RCI Header和Inode部分，其中Inode部分包含了指向LOB segment的指针，或者在In-line存储的情况下包含实际的LOB 数据。RCI(LOB Row-Column Intersection)即表Segment里存储的LOB列的所有数据，RCI Header里存储的是SecureFile的LOB控制信息。具体的定义如下：

2字节的Inode Layer整个的size，即表Segment里LOB列中，Locator Layer之外的size。如果是in-line存储的话也包括LOB数据的size在内。

1字节的flag，具体含义如下

0×01 此LOB是有效LOB

0×02 此inode在Index中

0×04此inode是in-line的

0×08 in-line的数据是实际的LOB数据

0×10 此inode是临时lob的控制结构

0×40此LOB是SecureFile的LOB

比如我们dump出block这里是0×48，就说明这个LOB是SecureFile的LOB，而且是in-line存储的。

1字节的SecureFile的LOB的选项flag：0×1是启用重复消除，0×2是启用压缩，0×4是启用加密。下面举例说明：

上文里创建过T11表，T11表没指定storage in row选项，因此就是默认的enable storage in row。给T11表插入两条测试数据，一条是in-line方式存储的，一条是out-of-line方式存储的：

SELECT id,dbms_lob.getlength(c1) FROM tst.t11;
ID DBMS_LOB.GETLENGTH(C1)
---------- ----------------------
1                     56
2                  25583
ALTER databas FLUSH buffer_cache;
SELECT dbms_rowid.rowid_to_absolute_fno(rowid,'TST','T11') fno,
dbms_rowid.rowid_block_number(rowid) bno,id FROM tst.t11;
FNO        BNO         ID
---------- ---------- ----------
5        132          1
5        132          2
ALTER system dump datafile 5 block 132;
SELECT value FROM v$diag_info WHERE name='Default Trace File';
VALUE
--------------------------------------------------------------------------------
/u01/app/oracle/diag/rdbms/dbeuc/dbeuc/trace/dbeuc_ora_25611.trc

先看第一条数据：

tab 0, row 0, @0x1f03
tl: 149 fb: --H-FL-- lb: 0x0  cc: 2
col  0: [ 2]  c1 02
col  1: [142]
 00 54 00 01 02 0c 80 80 00 02 00 00 00 01 00 00 00 61 3c c7 00 7a 48 90 00
 <- - - - - - A - - - - - - -> <- - - - - - B - - - - - - -> <- - C - -> <-   74 00 00 70 01 30 d3 30 b8 30 cd 30 b9 90 4b 55 b6 30 4c … … …  - - - D - - -> < - - - - - - - - - - E - - - - - - - - - … … …
LOB
Locator:
  Length:        84(142)
  Version:        1
  Byte Length:    2
  LobID: 00.00.00.01.00.00.00.61.3c.c7
  Flags[ 0x02 0x0c 0x80 0x80 ]:
    Type: CLOB
    Storage: SecureFile
    Characterset Format: IMPLICIT
    Partitioned Table: No
    Options: VaringWidthReadWrite
  SecureFile Header:
    Length:   122
    Old Flag: 0x48 [ DataInRow SecureFile ]
    Flag 0:   0x90 [ INODE Valid ]
    Layers:
      Lengths Array: INODE:116
      INODE:
        00 00 70 01 30 d3 30 b8 30 cd 30 b9 90 4b 55 b6 30 4c 30 88
        … … …

上面dump出的十六进制信息含义如下：

A：00 54 00 01 02 0c 80 80 00 02 Lob Locator Header

我认为这里的定义应该跟BasicFile没有发生变化：2字节的LOB locator长度（除这两个长度字节外）+ 2字节的LOB locator structure版本 + 4字节的FLAG + 2字节的字符集里字符的长度

B：00 00 00 01 00 00 00 61 3c c7 LOB ID

C：00 7a 48 90 RCI Header

0x007a（=122字节）：这个filed后的Inode的size（即D部分 + E部分的size）

0×48：这是in-line的SECUREFILE LOB

0×90：未启用重复消除，压缩，加密

D：00 74 00 00 70 01 Inode管理信息

0×0074（=116字节）：这个field后面（即后面的00 00 70 01四个字节 + E部分）Inode数据的size。116减4字节为112字节，这跟上面得到的LOB的length为56是能匹配上的。

0×0000：in-line存储LOB data。第二位的0表示后面LOB Data的size是用1字节表示

0×70（=112字节）：LOB Data的size

0×01：LOB Data的version

E：这里开始是真正的LOB Data

第二条：

tab 0, row 1, @0x1893
tl: 51 fb: --H-FL-- lb: 0x0  cc: 2
col  0: [ 2]  c1 03
col  1: [44]
 00 54 00 01 02 0c 80 80 00 02 00 00 00 01 00 00 00 61 3d 2e 00 18 40 90 00
 <- - - - - - A - - - - - - -> <- - - - - - B - - - - - - -> <- - C - -> <-   12 21 00 c7 de 0a 01 01 01 40 33 a2 01 01 01 40 33 14 06  - - - - D - - - - -> <- - - - - - - - E - - - - - - - ->
LOB
Locator:
  Length:        84(44)
  Version:        1
  Byte Length:    2
  LobID: 00.00.00.01.00.00.00.61.3d.2e
  Flags[ 0x02 0x0c 0x80 0x80 ]:
    Type: CLOB
    Storage: SecureFile
    Characterset Format: IMPLICIT
    Partitioned Table: No
    Options: VaringWidthReadWrite
  SecureFile Header:
    Length:   24
    Old Flag: 0x40 [ SecureFile ]
    Flag 0:   0x90 [ INODE Valid ]
    Layers:
      Lengths Array: INODE:18
      INODE:
        21 00 c7 de 0a 01 01 01 40 33 a2 01 01 01 40 33 14 06

上面dump出的十六进制信息含义如下：

A：Lob Locator Header

B：LOB ID

C：00 18 40 90 RCI Header

0×0018（=24字节）：这个filed后的Inode的size（即D部分 + E部分的size）

0×40：这是out-line的SECUREFILE LOB

0×90：未启用重复消除，压缩，加密

D：00 12 21 00 c7 de 0a 01 Inode管理信息

0×0012（=18字节）：这个field后面（即后面的四个字节 + E部分）Inode数据的size。

0×2100：第一位的2表示后面的E部分是chunk的RDBA + size，第二位的1表示后面LOB Data的size是用2字节表示

0xc7de（=51166字节）：LOB Data的size

0x0a： LOB Data的version

0×01：代表后面有2个chunk，如果是2就是3个chunk，以此类推。

E：01 01 40 33 a2 01 01 01 40 33 14 06

01 01 40 33 a2 01：RDBA以0x014033a2开头的1个block

01 01 40 33 14 06：RDBA以0×01403314开头的6个block

我们看一下第一个chunk：

SELECT DBMS_UTILITY.data_block_address_block(TO_NUMBER('14033a2','xxxxxxxx'))
bno FROM dual;
BNO
----------
13218

得到：

bdba    [0x014033a2]
kdlich  [0x2b4878d45a4c 56]
flg0  0x28 [ver=0 typ=data lock=y]
flg1  0x00
scn   0x0000.0045ff19
lid   00000001000000613d2e   - ->这是LOB ID
rid   0x00000000.0000
kdlidh  [0x2b4878d45a64 24]
flg2  0x00 [ver=0 lid=short-rowid hash=n cmap=n pfill=n]
flg3  0x00
pskip 0
sskip 0
hash  0000000000000000000000000000000000000000
hwm   8060   - ->这个block里存放了8060字节的数据
spr   0
data  [0x2b4878d45a80 52 8060]
30 d3 30 b8 30 cd 30 b9 90 4b 55 b6 30 4c 30 88 30 8a 89 07 96 d1 30 55 30 92

我们再看一下最后一个block：

SELECT DBMS_UTILITY.data_block_address_block(TO_NUMBER('1403314','xxxxxxxx'))
bno FROM dual;
BNO
----------
13076

现在需要dump从13076开始的第6个即13081号block，得到：

… … …
hwm   2806
… … …

一共8060×6+2806=51166字节的LOB data，这与前面的结果是能相互印证的。

下面我们再来看disable storage in row的情况下SecureFile是如何存储的。

在这种情况下指向LOB data的指针可能有两种存储方式：

第一种：LOB data的size不算很大的情况下，在Table Segment里的LOB列中以chunk的初始RDBA + size的方式存储，一个chunk信息接着一个chunk信息；

第二种：LOB data的size很大的情况下，在Table Segment里的LOB列中存储LHB（Lob Header Block）的信息，在LHB中存放所有chunk及size的列表。

第一种跟上面的第二条数据存储方式差不多，就不再介绍了，下面我们看第二种情况：

CREATE TABLE tst.t12 (id number,c2 CLOB) LOB (c2) STORE AS SECUREFILE(disable storage IN row);
插入一条很大的LOB数据：
SELECT id,dbms_lob.getlength(c2) FROM tst.t12;
        ID DBMS_LOB.GETLENGTH(C2)
---------- ----------------------
         1               49498672
ALTER databas FLUSH buffer_cache;
SELECT dbms_rowid.rowid_to_absolute_fno(rowid,'TST','T12') fno,
dbms_rowid.rowid_block_number(rowid) bno,id FROM tst.t12;
       FNO        BNO         ID
---------- ---------- ----------
         5        173          1
ALTER system dump datafile 5 block 173;

现在来看一下Table Segment里存放LOB列的地方是什么信息：

tab 0, row 0, @0x1f1b
tl: 44 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 2]  c1 02
col  1: [37]
 00 54 00 01 02 0c 80 80 00 02 00 00 00 01 00 00 00 61 3e 58 00 11 40 90 00
 < - - - - - - A - - - - - - > <- - - - - - B - - - - - - -> <- - C - -> <-   0b 43 00 05 e6 94 60 41 01 40 3b 81  - - - - D - - - - - - > <- - E - ->
LOB
Locator:
  Length:        84(37)
  Version:        1
  Byte Length:    2
  LobID: 00.00.00.01.00.00.00.61.3e.58
  Flags[ 0x02 0x0c 0x80 0x80 ]:
    Type: CLOB
    Storage: SecureFile
    Characterset Format: IMPLICIT
    Partitioned Table: No
    Options: VaringWidthReadWrite
  SecureFile Header:
    Length:   17
    Old Flag: 0x40 [ SecureFile ]
    Flag 0:   0x90 [ INODE Valid ]
    Layers:
      Lengths Array: INODE:11
      INODE:
        43 00 05 e6 94 60 41 01 40 3b 81

上面dump出的十六进制信息含义如下：

A：Lob Locator Header。

B：LOB ID

C：00 11 40 90 RCI Header

0×0018（=17字节）：这个filed后的Inode的size（即D部分 + E部分的size）

0×40：这是out-line的SECUREFILE LOB

0×90：未启用重复消除，压缩，加密

D：00 0b 43 00 05 e6 94 60 41 Inode管理信息

0x000b（=11字节）：这个field后面（即后面的四个字节 + E部分）Inode数据的size。

0×4300：第一位的4表示后面的E部分是LHB的RDBA，第二位的3表示LOB data的size是4字节。

0x05e69460（=98997344字节）：LOB Data的size

0×41： LOB Data的version

E：01 40 3b 81 这是LHB的RDBA

我们把LHB给dump出来看看：

SELECT DBMS_UTILITY.data_block_address_block(TO_NUMBER(LTRIM('01403b81'),'xxxxxxxx'))
BNO FROM dual;
BNO
----------
15233
ALTER system dump datafile 5 block 15233;

可以看到下面有chunk列表，以 block数 + RDBA的形式存储：

bdba    [0x01403b81]
kdlich  [0x2b3f1e77844c 56]
  flg0  0x18 [ver=0 typ=lhb lock=y]
  flg1  0x00
  scn   0x0000.00462283
  lid   00000001000000613e58
  rid   0x00000000.0000
kdlihh  [0x2b3f1e778464 24]
  flg2  0x00 [ver=0 lid=short-rowid hash=n it=n bt=n xfm=n ovr=n aux=n]
  flg3  0x80 [vll=y]
  flg4  0x00
  flg5  0x00
  hash  0000000000000000000000000000000000000000
  llen  0.98997344
  ver   0.65
  #ext  100
  asiz  100
  hwm   100
  ovr   0x00000000.0
  dba0  0x00000000
  dba1  0x00000000
  dba2  0x00000000
  dba3  0x00000000
  auxp  0x00000000
  ldba  0x01406ab5
nblk  12283   - ->这个LOB共占用了多少个block
[0] 0x00 0x00 73 0x014039b7   - ->从RDBA 0x014039b7 开始的73个block
[1] 0x00 0x00 7 0x014000c9   - ->从RDBA 0x014000c9开始的7个block
[2] 0x00 0x00 5 0x014000bb
… … … …
[97] 0x00 0x00 795 0x01406665
[98] 0x00 0x00 224 0x01406585
[99] 0x00 0x00 85 0x01406a61

接下来对于LOB data所在的block的dump这里就不做了，方法跟上述的类似。

5. 两种LOB性能测试比较

上面说了这么多新的SecureFile的LOB怎么怎么好，怎么怎么牛，大家一定有疑问了，是不是我在这忽悠大家呢。下面就给大家看些干货，真实的测试数据。

首先介绍下LOB参数：

LOGGING：在CREATE/UPDATE/INSERT LOB数据时会写入REDO LOG文件。但NOLOGGING会Internally转换成FILESYSTEM_LIKE_LOGGING，而FILESYSTEM_LIKE_LOGGING会确保数据库CRASH完整恢复

NOLOGGING：在CREATE/UPDATE/INSERT LOB数据时不写入REDO LOG文件。

FILESYSTEM_LIKE_LOGGING：数据库只记录LOB的METADATA到REDO LOG

NOCACHE：LOB数据不CACHE在SGA

CACHE：LOB数据CACHE在SGA

测试环境：

虚拟机OEL5.5 64bit + DB11.2.0.1，测试数据是一个110MB的文本文档lob.txt：

[oracle@cdcjp11vm1 ~]$ du -m lob.txt
110     lob.txt
[oracle@cdcjp11vm1 ~]$ cat lob.txt|wc -l
1916928
[oracle@cdcjp11vm1 ~]$ head –n1 lob.txt
ビジネス運営がより複雑さを増すなかで、ITに対する変化の要求は高まりを見せ、関連するリスクの軽減もあわせて求めら

创建了一个存储过程insert_clob（代码在附录中），作用是插入若干条CLOB数据即lob.txt的内容，本次测试每次是插20条数据，共2.2GB，记录所花的时间。

存储方式	DML类型	SecureFile	MB/s	BasicFile	MB/s	性能比%
CACHE + LOGGING	INSERT	54.152 s	40.626	243.726 s	9.027	450.05%
CACHE + NOLOGGING	INSERT	59.398 s	37.038	NOT support	-	-
NOCACHE + LOGGING	INSERT	43.799 s	50.229	289.213 s	7.607	660.23%
NOCACHE + NOLOGGING	INSERT	48.512 s	45.349	293.454 s	7.497	604.90%

结论已经很明显，新SecureFile格式的LOB性能相比较以前BasicFile有了巨大的提升，而且在最典型LOB的选项组合NOCACHE + LOGGING的情况下，性能提升的比例最大。

两种LOB的性能数据也可以参考这篇博文：

http://blog.sina.com.cn/s/blog_6058d7c10100nx26.html

他的测试结果如下，有的测试结果跟我的结果相比有一定的出入，可能是环境的问题，也可能是数据的问题（我是110MB的文本文件，他是5MB的文本文件），也可能是程序的问题（他用的java，我用的是PL/SQL）。另外他这篇文章里有关于SELECT（即READ）的性能数据，在NOCACHE + LOGGING的情况下，性能提升约三倍。

存储方式	DML类型	SecureFile MB/s	BasicFile MB/s	性能比%
CACHE + LOGGING	INSERT	9.17	8.64	106.13%
CACHE + LOGGING	SELECT	39.52	4.42	894.12%
CACHE + NOLOGGING	INSERT	31.56	-	-
CACHE + NOLOGGING	SELECT	35.31	-	-
NOCACHE + LOGGING	INSERT	36.63	2.32	1578.88%
NOCACHE + LOGGING	SELECT	50.28	16.28	308.85%
NOCACHE + NOLOGGING	INSERT	9.38	2.51	373.71%
NOCACHE + NOLOGGING	SELECT	5.54	11.36	48.76%

6. 总结及附录

做个总结吧，我认为SecureFile的LOB之所以比BasicFile的LOB性能有提升，就是因为可变chunk、LOB index不再使用、空闲空间搜索放到了shared pool里这三大原因共同决定的，尤其是后两者，比起以前的BasicFile LOB，架构设计上有了飞跃。我们也能看出虽然Oracle数据库的发展不像以前那么革命性了，但是在很多方面，新版本的Oracle数据库还是取得了巨大的进步。

附录：

测试表（只写了一种，其他的选项组合类似）：

CREATE TABLE tst.LOBTAB(ARTICLE_ID NUMBER PRIMARY KEY,ARTICLE_NAME VARCHAR2(50),
ARTICLE_DATA CLOB) tablespace DATA lob (ARTICLE_DATA) 
store AS SECUREFILE (tablespace DATA cache) LOGGING;
 
插入CLOB数据的存储过程insert_clob：
CREATE OR REPLACE procedure tst.insert_clob (fromid IN number,endid IN number)
AS
i NUMBER;
V_LOB CLOB;
V_FILE BFILE := BFILENAME('HOME_DIR', 'lob.txt');
V_SOURCE NUMBER := 1;
V_DEST NUMBER := 1;
V_LANG NUMBER := 0;
V_WARN NUMBER;
BEGIN
 
FOR i IN fromid..endid loop
V_SOURCE := 1;
V_DEST := 1;
INSERT INTO tst.LOBTAB VALUES (i, 'ABC'||to_char(i), 'TEST');
UPDATE tst.LOBTAB SET ARTICLE_DATA = EMPTY_CLOB WHERE ARTICLE_ID=i RETURN ARTICLE_DATA INTO V_LOB;
DBMS_LOB.FILEOPEN(V_FILE);
DBMS_LOB.OPEN(V_LOB, DBMS_LOB.LOB_READWRITE);
 
DBMS_LOB.LOADCLOBFROMFILE(
V_LOB,
V_FILE,
DBMS_LOB.GETLENGTH(V_FILE),
V_DEST,
V_SOURCE,
0,
V_LANG,
V_WARN);
 
DBMS_LOB.CLOSE(V_LOB);
DBMS_LOB.FILECLOSEALL;
COMMIT;
end loop;
END;
/
 
计算CLOB的INSERT操作的时间差是使用以下的PL/SQL：
declare
a VARCHAR2(50);
b VARCHAR2(50);
begin
SELECT to_char(systimestamp,'HH24:MI:SS.FF3') INTO a FROM dual;
TST.insert_clob(1,20);
SELECT to_char(systimestamp,'HH24:MI:SS.FF3') INTO b FROM dual;
dbms_output.put_line(a);
dbms_output.put_line(b);
end;
/

[zt]EXPDP和IMPDP的比较详细使用说明

Romeo — Sun, 16 Jan 2011 17:49:40 +0000

本打算自己写一篇关于data pump的blog，然后发现此文真的不错，就转载一下喽。http://space.itpub.net/11417069/viewspace-683740

ORCALE10G提供了新的导入导出工具，数据泵。Oracle官方对此的形容是：OracleDataPump technology enables Very High-Speed movement of data and metadata from one database to another.其中Very High-Speed是亮点。
先说数据泵提供的主要特性（包括，但不限于）：
1. 支持并行处理导入、导出任务
2. 支持暂停和重启动导入、导出任务
3. 支持通过Database Link的方式导出或导入远端数据库中的对象
4. 支持在导入时通过Remap_schema、Remap_datafile、Remap_tablespace几个参数实现导入过程中自动修改对象属主、数据文件或数据所在表空间。
5. 导入/导出时提供了非常细粒度的对象控制。通过Include、Exclude两个参数，甚至可以详细制定是否包含或不包含某个对象。

Warning:
1. 什么是Directory对象
Directory对象是Oracle10g版本提供的一个新功能。他是一个指向，指向了操作系统中的一个路径。每个Directory都包含Read,Write两个权限，可以通过Grant命令授权给指定的用户或角色。拥有读写权限的用户就可以读写该Directory对象指定的操作系统路径下的文件。

2. 无论在什么地方使用expdp，生成的文件最终页是在服务器上(Directory指定的位置)

如何调用
1. 命令行方式
最简单的调用，但是写的参数有限，建议使用参数文件的方式。

2. 参数文件方式
最常用的方式。通常需要先编写一个参数文件。指定导出时需要的各种参数。然后以如下方式调用。
expdp user/pwd parfile=xxx.par
这个xxx.par即是我们编辑的参数文件。注意，在这个命令行后面，同样可以再跟别的参数，甚至是在par参数文件中指定过的参数。如果执行命令中附加的参数与参数文件中的参数有重复，最终采用哪个参数，会以参数最后出现的位置而定。如：expdp user/pwd parfile=xxx.par logfile=a.log，如果在参数文件中也指定了logfile，这里会以命令行中的logfile为准；如：expdp user/pwd logfile=a.log parfile=xxx.par，而这个，则会以参数文件中的为准，因为parfile=xxx.par写在命令行的后面。

3. 交互方式
Data Pump导入导出任务支持停止，重启等状态操作。如用户执行导入或者导出任务，执行了一半时，使用Crtl+C中断了任务（或其他原因导致的中断），此时任务并不是被取消，而是被转移到后台。可以再次使用expdp/impdp命令，附加attach参数的方式重新连接到中断的任务中，并选择后续的操作。这就是交互方式。
Warning : 什么是attach参数，每执行一个导入，或者导出，在命令的第一行，会有以下信息：Starting “BAM”.”SYS_EXPORT_SCHEMA_01″: bam/******** parfile=expdp_tbs.par，这个SYS_EXPORT_SCHEMA_01就是我们的attach参数。
-bash-3.00$ expdp bam/bam parfile=expdp_tbs.par

Export: Release 10.2.0.4.0 – 64bit Production on Friday, 13 August, 2010 16:35:18

操作模式
1. 全库模式
导入或者导出整个数据库，对应impdp/expdp命令中的full参数，只有拥有dba或者exp_full_database和imp_full_database权限的用户才能执行。

2. Schema模式
导出或导入Schema下的自有对象，对应impdp/expdp命令中的Schema参数，这是默认的操作模式。如果拥有dba或者exp_full_database和imp_full_database权限的用户执行的话，就可以导出或导入多个Schema中的对象。

3. 表模式
导出指定的表或者表分区（如果有分区的话）以及依赖该表的对象（如该表的索引，约束等，不过前提是这些对象在同一个Schema中，或者执行的用户有相应的权限）。对应impdp/expdp命令中的Table参数。

4. 表空间模式
导出指定的表空间中的内容。对应impdp/expdp中的Tablespaces参数，这种模式类似于表模式和Schema模式的补充。

5. 传输表空间模式
对应impdp/expdp中的Transport_tablespaces参数。这种模式与前面几种模式最显著的区别是生成的Dump文件中并不包含具体的逻辑数据，而只导出相关对象的元数据(即对象的定义，可以理解成表的创建语句)，逻辑数据仍然在表空间的数据文件中，导出时需要将元数据和数据文件同时复制到目标端服务器。
这种导出方式效率很高，时间开销主要是花在复制数据文件产生的I/O上。expdp执行传输表空间模式的导出，用户必须拥有exp_full_database角色或者DBA角色。而通过传输表空间模式导入时，用户必须拥有imp_full_database角色或者DBA角色。

过滤数据
过滤数据主要依赖于Query和Sample两个参数。其中Sample参数主要针对expdp导出功能。
1. Query
与exp命令中的Query功能类似，不过Expdp中，该参数功能得到了增强，控制的粒度更细。Expdp中的Query也是指定类似where语句来限定记录。语法如下：
Query = [Schema.][Table_name:] Query_clause
默认情况如果不指定Schema.table_name,则Query_clause针对所有导出的表有效，或者你可以为每一个表指定不同的Query_clause，如：导出a表中所有id<5的记录，导出b表中所有name=’a'的记录，则Query的参数应该如下：
Query=A:”Where id<5″,B:”Where name=’a'”
如果Where条件前没有指定Schema名或者表名的话，默认就是针对当前所有要被导出的表。如：Query=Where id <5
Warning: 建议把Query参数放入到参数文件中使用，以避免转义符带来的麻烦。

2. Sample
该参数用来指定导出数据的百分比，可指定的值的范围从0.000001到99.999999，语法如下：
Sample=[[Schema_name.]Table_name:]sample_percent
指定该参数以后，EXPDP导出将自动控制导出的记录量，如导出A表中50%的记录，设置的Sample参数如下：
Sample=A:50
Warning: Sample_percent指定的值只是一个参考值，EXPDP会根据数据量算出一个近似值。

过滤对象
过滤对象主要依赖于Include和Exclude两个参数。这两个参数作用正好相反，在这两个参数中，可以指定你知道的任何对象类型（如：Package、Procedure、Table等等）或者对象名称（支持通配符）

1. Exclude 反规则
指定不被包含的对象类型或者对象名称。指定了该参数以后，指定的对象类型对应的所有对象都不会被导入或导出。如果被排除的对象有依赖的对象，那么其依赖的对象也不会被导入或导出。如：通过Exclude参数指定不导出表对象的话，不仅指定的表不会被导出，连这些表关联的Index、Check等都不会被导出。语法如下：
Exclude=object_type[:name_clause][, ...]
Warning: Exclude参数支持同时指定多个参数值，如：不导入A表的索引，也不导入B表的约束(假设A表的索引以idx_a开头，B表的约束以chk_b开头)，连所有的授权都不想导入，那么Exclude参数设置如下：
Exclude=Index:”like ‘idx_a%’”, Constraint:”like ‘chk_b%’”, Grant
Warning: 建议把Exclude参数放入到参数文件中使用，以避免转义符带来的麻烦。

2. Include 正规则
与Exclude正好相反。指定包含的对象类型或者对象名称。
Warning: 由于两个参数功能正好相反，因此在执行导入或导出命令时，两个参数不能同时使用，否则Oracle也不知道你想要干什么啦。

高级过滤
在导出/导入的时候，我们常常有这样的需求，只想导出/导入表结构，或者只想导出/导入数据。幸运的是数据泵也提供了该功能。使用Content参数。该参数有三个属性
1) ALL : 导出/导入对象定义和数据，该参数的默认值就是ALL
2) DATA_ONLY : 只导出/导入数据。
3) METADATA_ONLY : 只导出/导入对象定义。

Warning: 有一点值得注意的时，在执行导出的时候，如果使用了高级过滤，如只导出了数据，那么导入时，需要确保数据定义已经存在。否则数据都变成没有主子了。如果数据定义已经存在，导入时最好指定data_only，否则会触发ORA-39151错误，因为对象已经存在了。

过滤已经存在的数据
我们知道，导入的表对象在目标库中已经存在，并且目标端没有创建数据完整性约束条件(RI)来检验数据的话，就有可能造成数据被重复导入。数据泵提供了一个新的参数Table_exists_action,可以一定程度上降低重复数据的产生。该参数用来控制如果要导入的表对象存在，执行什么操作。有以下几个参数值：
1) SKIP : 跳过该表，继续处理下一个对象。该参数默认就是SKIP。值得注意的是，如果你同时指定了CONTENT参数为Data_only的话，SKIP参数无效，默认为APPEND。
2) APPEND : 向现有的表中添加数据。
3) TRUNCATE : TRUNCATE当前表，然后再添加记录。使用这个参数需要谨慎，除非确认当前表中的数据确实无用。否则可能造成数据丢失。
4) REPLACE : 删除并重建表对象，然后再向其中添加数据。值得注意的是，如果同时指定了CONTENT参数为Data_only的话，REPLACE参数无效。

重定义表的Schema或表空间
我们还可能会遇到这样的需求，把A用户的对象转移到B用户，或者更换数据的表空间。数据泵通过Remap_Schema和Remap_tablespace参数实现了该功能。
1) REMAP_SCHEMA : 重定义对象所属Schema
该参数的作用类似IMP中的Fromuser+Touser,支持多个Schema的转换，语法如下：
REMAP_SCHEMA=Source_schema:Target_schema[,Source_schema:Target_schema]
如把A的对象转换到C用户，将C转换到D用户。Remap_schema=a:b,c:d
Warning: 不能在同一个IMPDP命令中指定remap_schema=a:b,a:c.

2) REMAP_TABLESPACE : 重定义对象所在的表空间。
该参数用来重映射导入对象存储的表空间，支持同时对多个表空间进行转换，相互间用逗号分割。语法如下：
REMAP_TABLESPACE=Source_tablespace:Target_tablespace[,Source_tablespace:Target_tablespace]
Warning: 如果使用Remap_tablespace参数，则要保证导入的用户对目标表空间有读写权限。

优化导入/导出效率
对于大数据量来说，我们不得不考虑效率问题。数据泵对效率也提出了更高的要求。甚至官方的描述就是Oracle Data Pump technology enables Very High-Speed movement of data and metadata from one database to another.这里的Very High-Speed依赖我们的parallel参数。
所有的优化操作都会有三种结果：变得更好、没有变化、变得更差。Parallel参数也是这样，并不是指定一个大于1的参数，性能就会有提升。
1) 对于导出的parallel
对于导出来说，由于dump文件只能由一个线程进行操作（包括I/O处理），因此如果输出的DUMP文件只有一个，即使你指定再多的并行，实际工作仍然是一个，而且还会触发ORA-39095错误。因此，建议设置该参数小于或等于生成的DUMP文件数量。那么，如何控制生成的DUMP文件数量呢？
EXPDP命令提供了一个FILESIZE参数，用来指定单个DUMP文件的最大容量，要有效的利用parallel参数，filesize参数必不可少。
举例：某用户对象占用了4G左右的空间，实际导出后的DUMP文件约为3G，我们尝试在导出该用户时指定并行度为4，设置单个文件不超过500M，则语法如下：
$ expdp user/pwd directory=dump_file dumpfile=expdp_20100820_%U.dmp logfile=expdp_20100820.log filesize=500M parallel=4

2) 对于导入的parallel
对于导入来说，使用parallel参数则要简单的多，我认为导入更能体现parallel参数的优势。参数设置为几，则认为同时将几张表的内容导入到库中。
举例：某dmp文件中包含了200张表，我们尝试在导入该DMP文件时指定并行度为10，则语法如下：
$ impdp user/pwd directory=dump_file dumpfile=expdp_20100820.dmp logfile=impdp_20100820.log parallel=10

执行导出
1. 如何起步
前面介绍了一些基本知识，现在我们来试试如何操作吧。
举例如下：从10.1.133.98服务器上，将除数据之外的所有信息导入到10.1.133.88数据库中。
1) 创建一个Directory对象，并授予用户读写权限。
SQL> create directory dump_file as ‘/home/oracle/backup’;

Directory created.

SQL> grant read,write on directory dump_file to bam;

Grant succeeded.
如上，生成的DMP文件将会放在/home/oracle/backup目录下。

2) 编写一个导出的参数文件。
-bash-3.00$ vi expdp_tbs.par
DIRECTORY=DUMP_FILE
DUMPFILE=expdp_bamdb2bamtest.dmp
LOGFILE=expdp_bamdb2bamtest.log
CONTENT=METADATA_ONLY
如上，指定了生成的dmp文件名以及日志名（这些都会被放在/home/oracle/backup下），以及导出模式为：metadata_only–只导出结构，不包含数据。

3) 执行导出命令
-bash-3.00$ expdp bam/bam parfile=expdp_tbs.par

Export: Release 10.2.0.4.0 – 64bit Production on Friday, 13 August, 2010 16:35:18

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting “BAM”.”SYS_EXPORT_SCHEMA_01″: bam/******** parfile=expdp_tbs.par
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TYPE/TYPE_SPEC
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/FUNCTION/FUNCTION
Processing object type SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Processing object type SCHEMA_EXPORT/FUNCTION/ALTER_FUNCTION
Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processing object type SCHEMA_EXPORT/VIEW/VIEW
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_AND_BITMAP/INDEX
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/FUNCTIONAL_AND_BITMAP/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/JOB
Master table “BAM”.”SYS_EXPORT_SCHEMA_01″ successfully loaded/unloaded
******************************************************************************
Dump file set for BAM.SYS_EXPORT_SCHEMA_01 is:
/home/oracle/backup/expdp_bamdb2bamtest.dmp
Job “BAM”.”SYS_EXPORT_SCHEMA_01″ successfully completed at 16:41:26

4) 将文件传输到10.1.133.88机器上。
-bash-3.00$ ftp 10.1.133.88
Connected to 10.1.133.88.
220 BNM-TEST2 FTPserverready.
Name (10.1.133.88:oracle): oracle
331 Password required for oracle.
Password:
230 User oracle logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> bin
200 Type set to I.
ftp> put /home/oracle/backup/expdp_bamdb2bamtest.dmp /export/app22/backup/expdp_bamdb2bamtest.dmp
200 PORT command successful.
150 Opening BINARY mode data connection for /export/app22/backup/expdp_bamdb2bamtest.dmp.
226 Transfer complete.
local: /home/oracle/backup/expdp_bamdb2bamtest.dmp remote: /export/app22/backup/expdp_bamdb2bamtest.dmp
125329408 bytes sent in 1.4 seconds (89551.55 Kbytes/s)
ftp> bye
221-You have transferred 125329408 bytes in 1 files.
221-Total traffic for this session was 125329890 bytes in 1 transfers.
221-Thank you for using the FTP service on BNM-TEST2.
221 Goodbye.

5) 执行导入
-bash-3.00$ impdp bam/bam directory=dump_file dumpfile=expdp_bamdb2bamtest.dmp logfile=expdp_bamdb2bamtest.log table_exists_action=replace

Import: Release 10.2.0.4.0 – 64bit Production on Friday, 13 August, 2010 16:44:51

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table “BAM”.”SYS_IMPORT_FULL_01″ successfully loaded/unloaded
Starting “BAM”.”SYS_IMPORT_FULL_01″: bam/******** directory=dump_file dumpfile=expdp_bamdb2bamtest.dmp logfile=expdp_bamdb2bamtest.log table_exists_action=replace
Processing object type SCHEMA_EXPORT/USER
ORA-31684: Object type USER:”BAM” already exists
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TYPE/TYPE_SPEC
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/TABLE/TABLE
…

6) 如何进入交互模式
在这里，我正在执行导入，我想进入交互模式，查看导入的状态。进入交互模式有两种方式，操作步骤如下：
i 使用Ctrl+C退出当前模式
ii 在命令行模式下，执行Expdp/Impdp命令，同时指定attach参数连接到当前正在制定的导入/导出任务。如：
expdp bam/bam attach=SYS_IMPORT_FULL_01
Warning:如果没有指定Attach参数，则默认进入当前正在运行的任务。不过如果当前没有正在指定的任务，而且也没有给Attach赋值，那么就会报Ora-31626错误。
当命令行进入交互模式后，会显示如下界面：
Export>
7) 交互模式的操作
在交互模式中，支持下面几种操作。
i 查看JOB的运行状态
Export> status
ii 回退到命令行
Export> continue_client
iii 增加并行
Export> parallel=4
Warning: 在使用导出时，不能直接指定parallel参数，否则可能会遇到ORA-39095错误，因为如果要并行导出，则必须指定多个导出文件，这里的并行导出是指，多个线程同时工作，同时从数据库中导出多个dmp文件来。
在Oracle Database Utilities中有如下解释：
Because each active worker process or I/O server process writes exclusively to one file at a time, an insufficient number of files can have adverse effects. Some of the worker processes will be idle while waiting for files, thereby degrading the overall performance of the job. More importantly, if any member of a cooperating group of parallel I/O server processes cannot obtain a file for output, then the export operation will be stopped with an ORA-39095 error. Both situations can be corrected by attaching to the job using the Data Pump Export utility, adding more files using the ADD_FILE command while in interactive mode, and in the case of a stopped job, restarting the job.

You can supply multiple file_name specifications as a comma-delimited list or in separate DUMPFILE parameter specifications. If no extension is given for the filename, then Export uses the default file extension of .dmp. The filenames can contain a substitution variable (%U), which implies that multiple files may be generated. The substitution variable is expanded in the resulting filenames into a 2-digit, fixed-width, incrementing integer starting at 01 and ending at 99. If a file specification contains two substitution variables, both are incremented at the same time. For example, exp%Uaa%U.dmp would resolve to exp01aa01.dmp, exp02aa02.dmp, and so forth.

iv 停止JOB
Export> stop_job
v 启动JOB
Export> start_job
vi 杀掉JOB
Export> kill_job
vii 退出交互模式
Export> exit_client
viii 指定文件大小
Export> filesize=1G
ix 帮助
Export> Help

CLOB的物理存储结构及语言编码详解

Romeo — Thu, 06 Jan 2011 08:50:23 +0000

最近测试一个工具Database Migration for Unicode，功能是把非unicode编码存储数据的数据库转化为Unicode的数据库。在guide中提到一句，CLOB类型的列无需转换编码，这句话引起我的兴趣，为何别的字符类型char或者varchar2都需要编码转换，为什么CLOB不需要。在网上搜索，找到了DBSNAKE的这篇文章（http://dbsnake.com/2010/07/lob-characterset-endian.html）。里面提到了一篇Note [ID 257772.1],核心意思是，基本上从10g之后的CLOB的字符编码无论在何种CharacterSet下均为AL16UTF16。现在特来验证一下。

1. 在JA16EUC的数据库中创建测试用户及测试表(LOB存储为disable storage in row)

SELECT value FROM nls_database_parameters WHERE PARAMETER='NLS_CHARACTERSET';
 
VALUE
 
------------------------
 
JA16EUC
 
CREATE TABLE tst.tab1(col1 CLOB) tablespace DATA
lob (col1) store AS (tablespace DATA disable storage IN row nocache);
 
INSERT INTO tst.tab1 VALUES(’ビジネス運営’);
 
commit;

找出这一行存储的物理文件和block

SELECT dbms_rowid.rowid_block_number(rowid) bno,col1 FROM tst.tab1;
 
BNO COL1
 
---------- ------------------------------
 
135 ビジネス運営
 
SELECT FILE_NAME,FILE_ID FROM dba_data_files;
 
FILE_NAME                                             FILE_ID
 
-------------------------------------------------- ----------
 
/u01/app/oracle/oradata/euc2/system01.dbf                   1
 
/u01/app/oracle/oradata/euc2/sysaux01.dbf                   2
 
/u01/app/oracle/oradata/euc2/undotbs01.dbf                  3
 
/u01/app/oracle/oradata/euc2/users01.dbf                    4
 
/u01/app/oracle/oradata/euc2/DATA.dbf                       5
 
ALTER system dump datafile 5 block 135;

在udump里找到对应的trace文件，因为使用的是11gR2，所以路径略有不同

SELECT value FROM v$diag_info WHERE name='Default Trace File';
 
VALUE
 
----------------------------------------------------------------
 
/u01/app/oracle/diag/rdbms/euc2/euc2/trace/euc2_ora_6234.trc

在上述trace里找到

block_row_dump:

tab 0, row 0, @0x1f80

tl: 24 fb: –H-FL– lb: 0×1 cc: 1

col 0: [20] 00 54 00 01 02 08 80 00 00 02 00 00 00 01 00 00 00 2d c8 b5 –>这里后10个字节就是LobID

LOB

Locator:

Length: 84(20)

Version: 1

Byte Length: 2

LobID: 00.00.00.01.00.00.00.2d.c8.b5

Flags[ 0x02 0x08 0x80 0x00 ]:

Type: CLOB

Storage: BasicFile

Disable Storage in Row

Characterset Format: IMPLICIT –>可以发现这里并没有写明CLOB字段所使用的编码

Partitioned Table: No

Options: VaringWidthReadWrite

这里就需要介绍一下LOB在enable还是disable storage in row这两种模式下的存储格式。

先看一下我们这个含有LOB的TAB1表有哪些相关的segment：

SELECT SEGMENT_NAME,SEGMENT_TYPE FROM dba_segments WHERE OWNER='TST';
 
SEGMENT_NAME                             SEGMENT_TYPE
 
---------------------------------------- ---------------
 
TAB1                                     TABLE
 
SYS_IL0000017724C00001$$                 LOBINDEX
 
SYS_LOB0000017724C00001$$                LOBSEGMENT

背景知识，LOB是Large Object（大对象）的简称，包括CLOB，NCLOB，BLOB，BFILE。这里我们讨论的只是CLOB。创建每一个LOB列除了表中的一个column外，另外同时还创建了两个物理结构：LOB index和LOB segment。

首先，需要了解的是在默认情况下LOB segment是和其所在的table存储在一起的，即in-line。而另外一种，LOB的访问是通过LOB locator来访问LOB index，LOB index再指向真正的物理存储数据的地方即LOB segment里的chunk。LOB locator就是指向LOB index的Key。

接下来先看一下Enable storage in row的方式下LOB的存储。这里分为两种情况，小于4000字节和大于4000字节。

LOB字段的locator加Inode加LOB的内容总长度小于4000字节时：

Col1	LOB Col
1	Locator1，Inode 1，LOB data 1
2	Locator2，Inode 2，LOB data 2

这里LOB字段的存储是按如下的格式：

2字节的LOB locator长度（除这两个长度字节外）
2字节的LOB locator structure版本
4字节的FLAG
2字节的字符集里字符的长度
10字节的LOB ID
16字节的inode

之后就是LOB data，所以这里in-line的情况下理论上最多能存储4000-2-2-4-2-10-16=3964字节。

其他情况：

Col1	LOB Col		LOB Col
1	Locator1，Inode 1	——–>	LOB data 1
2	Locator2，Inode 2	——–>	LOB data 2

就是说即使Enable storage in row，LOB字段在LOB的控制信息（即Locator加Inode）长度加LOB data长度大于4000字节的时候，LOB data也是不存储在row内部的。在表里LOB字段的第36-84字节存储的是LOB data的前12个chunk的RDBA。如果12个不够的情况下，这里存放的不是chunk的RDBA，而是LOB index的RDBA。

另外，在Disable storage in row的方式下，数据都是这么存储的：

Col1	LOB Col		LOB Index		LOB Storage
1	Locator1	——>	Inode 1	——>	LOB data 1
2	Locator2	——>	Inode 2	——>	LOB data 2

LOB index是一个类似于unique index的结构。这里我们把LOB index的叶子块的信息dump出来。

先找出TAB1的OBJ#：

SELECT object_id FROM dba_objects WHERE object_name='TAB1';
 
OBJECT_ID
 
----------
 
17724
 
再找出TAB1里的LOB INDEX的ind#：
 
SELECT IND# from lob$ where OBJ#='17724';
 
IND#
 
----------
 
17726

把这个index的tree给dump出来：

ALTER session SET events 'immediate trace name treedump level 17726';
 
SELECT value FROM v$diag_info WHERE name='Default Trace File';
 
VALUE
 
-------------------------------------------------------------
 
/u01/app/oracle/diag/rdbms/euc2/euc2/trace/euc2_ora_11704.trc

从上面这个trace中找到：

—– begin tree dump

leaf: 0×1400093 20971667 (0: nrow: 1 rrow: 1)

—– end tree dump
解释：前两列分别是RDBA的十六进制和十进制地址，由此可以得出leaf block的number。Nrow 是行数，如果是branch block的话就是child nodes的个数。

SELECT DBMS_UTILITY.data_block_address_block(TO_NUMBER(LTRIM('1400093'),'xxxxxxxx'))
 BNO FROM dual;
 
BNO
 
----------
 
147
 
ALTER system dump datafile 5 block 147;

得到50个字节的LOB index

row#0[7982] flag: ——, lock: 2, len=50, data:(32):

00 20 03 00 00 00 00 00 00 0c 00 00 00 00 00 01 01 40 00 8f 00 00 00 00 00

00 00 00 00 00 00 00

col 0; len 10; (10): 00 00 00 01 00 00 00 2d c8 b5

col 1; len 4; (4): 00 00 00 00

LOB index的结构是：

长度为50个byte，具体组成如下：

行头flag（1个byte）

lock byte（1个byte）

lob index key ( 32个byte，要么由16个byte的lob inode+4个RDBA组成，要么由8个RDBA组成。Disable storage in row的情况下是前者)

lob id的长度（1个byte）＋ lob id（10个byte）

page number的长度（1个byte）

page number（4个byte）

Inode的结构是：

2字节的in-line的data的长度

1字节的inode标志位：1代表这是个有效的lob，2代表这个inode在LOB index里，3代表这个lob是个有效的lob，而且在LOB index里

1字节的预留位

4字节full oracle blocks数量

2字节最后一个page里有多少byte的数据

6字节的LOB version，0×0001.00000000的形式

所以这里01 40 00 8f就是第一个chunk的RDBA的地址。

SELECT DBMS_UTILITY.data_block_address_block(TO_NUMBER(LTRIM('0140008f'),'xxxxxxxx'))
 BNO FROM dual;
 
BNO
 
----------
 
143
 
ALTER system dump datafile 5 block 143;

可以从trace中得到CLOB字段的实际存储的物理格式：

Long field block dump:

Object Id 17725

LobId: 00010002DC8B5 PageNo 0

Version: 0×0000.00000000 pdba: 20971656

30 d3 30 b8 30 cd 30 b9 90 4b 55 b6 00 20 00 20 00 20 00 20 00 20 00 20

我们验证一下这里的十六进制码到底跟哪个CharSet里的文字的物理格式一样：

CREATE TABLE aaa (col1 varchar2(100),col2 nvarchar2(100));
 
INSERT INTO aaa VALUES ('ビジネス運営','ビジネス運営');
 
SELECT dump(col1,1016),dump(col2,1016) FROM aaa;
 
DUMP(COL1,1016)
 
--------------------------------------------------------------------------------
 
DUMP(COL2,1016)
 
--------------------------------------------------------------------------------
 
Typ=1 Len=12 CharacterSet=JA16EUC: a5,d3,a5,b8,a5,cd,a5,b9,b1,bf,b1,c4
 
Typ=1 Len=12 CharacterSet=AL16UTF16: 30,d3,30,b8,30,cd,30,b9,90,4b,55,b6

可见CLOB的物理存储格式并不是JA16EUC，而是AL16UTF16。

在研究这个东西的过程中得到了崔华（http://dbsnake.com）的大力帮助，在这里表示感谢。

参考：

DSI 402e：P52-P57，P250-P254

http://dbsnake.com/2010/07/some-lob-internal.html

全文PDF版本（排版好看很多）在这里 CLOB_Storage_Charset.pdf

在11gR2中编译BBED工具

Romeo — Mon, 20 Dec 2010 07:22:17 +0000

11gR2中编译bbed时报错

[oracle@cdcjp11vm1 lib]$ make -f ins_rdbms.mk BBED=$ORACLE_HOME/bin/bbed $ORACLE_HOME/bin/bbed
 
Linking BBED utility (bbed)
rm -f /u01/app/oracle/product/11.2.0/dbhome_1/bin/bbed
gcc -o /u01/app/oracle/product/11.2.0/dbhome_1/bin/bbed -m64 -L/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ -L/u01/app/oracle/product/11.2.0/dbhome_1/lib/ -L/u01/app/oracle/product/11.2.0/dbhome_1/lib/stubs/  /u01/app/oracle/product/11.2.0/dbhome_1/lib/s0main.o /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ssbbded.o /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/sbbdpt.o `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -ldbtools11 -lclntsh  `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnro11 `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnnz11 -lzt11 -lztkg11 -lztkg11 -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11 -lmm -lsnls11 -lnls11  -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnro11 `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11   -lsnls11 -lnls11  -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11 -lsnls11 -lnls11  -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11   `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/sysliblist` -Wl,-rpath,/u01/app/oracle/product/11.2.0/dbhome_1/lib -lm    `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/sysliblist` -ldl -lm   -L/u01/app/oracle/product/11.2.0/dbhome_1/lib
gcc: /u01/app/oracle/product/11.2.0/db/rdbms/lib/ssbbded.o: No such file or directory
gcc: /u01/app/oracle/product/11.2.0/db/rdbms/lib/sbbdpt.o: No such file or directory
make: *** [/u01/app/oracle/product/11.2.0/db/rdbms/lib/bbed] Error 1

gcc提示有两个链接库无法找到，这时我们可以从10.2的同一路径下把它们拷过来

[oracle@cdcjp08vm1 lib] scp *bb* cdcjp11vm1:/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib

这时可以make了，但是使用是还是会报错

[oracle@cdcjp11vm1 lib]$ make -f ins_rdbms.mk BBED=$ORACLE_HOME/bin/bbed $ORACLE_HOME/bin/bbed
 
Linking BBED utility (bbed)
rm -f /u01/app/oracle/product/11.2.0/dbhome_1/bin/bbed
gcc -o /u01/app/oracle/product/11.2.0/dbhome_1/bin/bbed -m64 -L/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ -L/u01/app/oracle/product/11.2.0/dbhome_1/lib/ -L/u01/app/oracle/product/11.2.0/dbhome_1/lib/stubs/  /u01/app/oracle/product/11.2.0/dbhome_1/lib/s0main.o /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ssbbded.o /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/sbbdpt.o `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -ldbtools11 -lclntsh  `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnro11 `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnnz11 -lzt11 -lztkg11 -lztkg11 -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11 -lmm -lsnls11 -lnls11  -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnro11 `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11   -lsnls11 -lnls11  -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11 -lsnls11 -lnls11  -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11   `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/sysliblist` -Wl,-rpath,/u01/app/oracle/product/11.2.0/dbhome_1/lib -lm    `cat /u01/app/oracle/product/11.2.0/dbhome_1/lib/sysliblist` -ldl -lm   -L/u01/app/oracle/product/11.2.0/dbhome_1/lib
 
[oracle@cdcjp11vm1 lib]$ bbed
Message 112 not found; No message file for product=RDBMS, facility=BBED
BBED-00113: file not found

这是因为bbed 需要用到bbedus.msg和bbedus.msb 2个信息文件，也需要拷过来

[oracle@cdcjp08vm1 mesg] scp bbedus.ms* cdcjp11vm1:/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/mesg/
[oracle@cdcjp11vm1 mesg]$ bbed
Password:
 
BBED: Release 2.0.0.0.0 - Limited Production on 月 12月 20 15:17:21 2010
 
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
 
************* !!! For Oracle Internal Use only !!! ***************
 
BBED&gt;

这里的密码不是DB的密码，是BBED自己的密码，小写的“blockedit”

参考

http://www.oracledatabase12g.com/archives/how-to-make-bbedoracle-block-brower-and-editor-tool-on-unixlinuxwindows.html

Oracle 11.2.0.2新特性——用户重命名(Rename User)

Romeo — Tue, 07 Sep 2010 02:22:59 +0000

11.2.0.2里新增了一个很有意思的新特性——用户重命名(Rename User)，以前俺们都是Rename datafile呀，tablespace呀，Index呀，抑或是constraint之类，没想到User也可以重命名的。据说这个DDL操作的需求是来源于SAP: SAP identifies a specific SAP system by the name of the database schema. If the system is renamed, the schema needs also to be renamed. This happens quite often when a database is copied (i.e. for testing purposes) and the system gets therefore a new name. The schema should also get a new name.

废话不多说，验证一下先：

创建测试用户下一个测试表，查看testusr的ID是84

SQL> CREATE TABLE testusr.emp AS SELECT * FROM scott.emp;
SQL> SELECT USERNAME,USER_ID FROM dba_users WHERE created>(sysdate-1);
USERNAME                          USER_ID
------------------------------ ----------
TESTUSR                                84

启用重命名特性需要修改隐含参数“_enable_rename_user”，并需要在restrict mode下Rename

SQL> CREATE  pfile FROM spfile;
[oracle@cdcjp47 dbhome_1]$ vi dbs/initeastdb.ora
-- 添加
*._enable_rename_user=TRUE
SQL> shutdown immediate
SQL> startup restrict pfile='?/dbs/initeastdb.ora'
SQL> ALTER user testusr RENAME TO testusr1 IDENTIFIED BY Welcome1;
SQL> SELECT USERNAME,USER_ID FROM dba_users WHERE created>(sysdate-1);
 
USERNAME                          USER_ID
------------------------------ ----------
TESTUSR1                               84
-- 看看数据，都在的，说明Rename User并不影响Object里面的内容
SQL> SELECT * FROM testusr1.emp;
     EMPNO ENAME    JOB               MGR HIREDATE        SAL       COMM     DEPTNO
---------- -------- ---------- ---------- -------- ---------- ---------- ----------
      7369 SMITH    CLERK            7902 80-12-17        800                    20
      7499 ALLEN    SALESMAN         7698 81-02-20       1600        300         30
      7521 WARD     SALESMAN         7698 81-02-22       1250        500         30
      7566 JONES    MANAGER          7839 81-04-02       2975                    20
      7654 MARTIN   SALESMAN         7698 81-09-28       1250       1400         30
      7698 BLAKE    MANAGER          7839 81-05-01       2850                    30
      7782 CLARK    MANAGER          7839 81-06-09       2450                    10
      7788 SCOTT    ANALYST          7566 87-04-19       3000                    20
      7839 KING     PRESIDENT             81-11-17       5000                    10
      7844 TURNER   SALESMAN         7698 81-09-08       1500          0         30
      7876 ADAMS    CLERK            7788 87-05-23       1100                    20
      7900 JAMES    CLERK            7698 81-12-03        950                    30
      7902 FORD     ANALYST          7566 81-12-03       3000                    20
      7934 MILLER   CLERK            7782 82-01-23       1300                    10

注意新用户名不要和现有用户名重名

SQL> ALTER user testusr1 RENAME TO scott IDENTIFIED BY 123;
ALTER user testusr1 RENAME TO scott IDENTIFIED BY 123
*
ERROR IN Line 1：
ORA-00604: error occurred at recursive SQL level 1. 
ORA-00001:UNIQUE constraint (SYS.I_USER1) violated

Physical Standby出现ORA-10458，ORA-01157，ORA-01111

Romeo — Thu, 15 Jul 2010 07:13:45 +0000

今天在测试系统中启动Physical Standby，发现报错，最终查出原因是有人在测试库中创建了个tablespace而且把datafile没有放在默认path，导致db_file_name_convert没有产生作用。

系统环境：DB11.2.0.2，Primary和Standby都在同一台主机上

SQL> startup
ORACLE instance started.
 
Total System Global Area  627732480 bytes
Fixed Size                  1345768 bytes
Variable Size             411043608 bytes
DATABASE Buffers          209715200 bytes
Redo Buffers                5627904 bytes
DATABASE mounted.
ORA-10458: standby DATABASE requires recovery
ORA-01157: cannot identify/LOCK DATA file 7 -
see DBWR trace file.
ORA-01111:name FOR DATA file 7 IS unknown - RENAME TO correct file
ORA-01110: DATA file 7: '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED00007'
 
 
SQL> SELECT name FROM v$datafile;
 
NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcldg/system01.dbf
/u01/app/oracle/oradata/orcldg/sysaux01.dbf
/u01/app/oracle/oradata/orcldg/undotbs01.dbf
/u01/app/oracle/oradata/orcldg/users01.dbf
/u01/app/oracle/oradata/orcldg/soe.dbf
/u01/app/oracle/oradata/orcldg/soeindex.dbf
/u01/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED00007
 
SQL> SHOW parameter convert
 
NAME                                 TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
db_file_name_convert                 string
/u01/app/oracle/oradata/orcl,
/u01/app/oracle/oradata/orcldg
log_file_name_convert                string
/u01/app/oracle/oradata/orcl,
/u01/app/oracle/oradata/orcldg
 
SQL> !

[oracle@cdcjp28 ~]$ vi diag/rdbms/orcldg/orcldg/trace/alert_orcldg.log
Thu Jul 15 16:11:35 2010
WARNING: File being created with same name as in Primary
Existing file may be overwritten
Errors in file /u01/app/oracle/product/11.2.0/dbhome_1/diag/rdbms/orcldg/orcldg/trace/orcldg_pr00_5141.trc:
ORA-01119: error in creating database file ‘/u01/app/oracle/product/11.2.0/dbhome_1/dbs/sh.dbf’
ORA-27086: unable to lock file – already in use
Linux Error: 11: Resource temporarily unavailable
Additional information: 8
Additional information: 29207
File #7 added to control file as ‘UNNAMED00007′.
Originally created as:
‘/u01/app/oracle/product/11.2.0/dbhome_1/dbs/sh.dbf’
Recovery was unable to create the file as:
‘/u01/app/oracle/product/11.2.0/dbhome_1/dbs/sh.dbf’
MRP0: Background Media Recovery terminated with error 1274
Errors in file /u01/app/oracle/product/11.2.0/dbhome_1/diag/rdbms/orcldg/orcldg/trace/orcldg_pr00_5141.trc:
ORA-01274: cannot add datafile ‘/u01/app/oracle/product/11.2.0/dbhome_1/dbs/sh.dbf’ – file could not be created
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!

解决方案是先把standby_file_management设置为手动，把添加的数据文件拷到备库放datafile的地方，rename到这个新位置，然后把standby_file_management设置为auto，重启备库，搞定！

[oracle@cdcjp28 ~]$ cp /u01/app/oracle/product/11.2.0/dbhome_1/dbs/sh.dbf /u01/app/oracle/oradata/orcldg/sh.dbf

SQL> ALTER system SET standby_file_management='manual';
 
System altered.
 
SQL> ALTER DATABASE RENAME file '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED00007' 
     TO '/u01/app/oracle/oradata/orcldg/sh.dbf';
 
System altered.
 
SQL> ALTER system SET standby_file_management='auto';
 
System altered.
 
SQL> shutdown immediate
 
SQL> startup

EM dbcontrol的常用命令

Romeo — Mon, 05 Jul 2010 07:25:30 +0000

详细的命令列表还是看OTN（http://download.oracle.com/docs/cd/E11882_01/server.112/e10701/emca.htm#BABDEHCE），下面只列出一些常见的：

创建DBcontrol：emca -config dbcontrol db -repos create

RAC下重新部署DBcontrol：emca -reconfig dbcontrol -cluster

删除DBcontrol：emca -deconfig dbcontrol db -repos drop

更改port：emca -reconfig ports [-cluster] -DBCONTROL_HTTP_PORT port_number

重新配置RAC里EM的位置，比如从A节点到B节点：
emca -reconfig dbcontrol -cluster -EM_NODE nodename -EM_NODE_LIST NODE_list
-EM_NODE DBcontrol的Node名，默认是此命令运行的本地节点
-EM_NODE_LIST 默认是此RAC配置过的所有节点

增加管理的节点：在已经配置了em的节点上运行，填写新加的节点信息
emca -addNode db

删除节点：在不删除的节点上运行，填写删除的节点信息
emca -deleteNode db

EMGC11g内存占用100%问题

Romeo — Sat, 12 Jun 2010 03:28:38 +0000

EMGC11g测试机上的内存占用总是过一段时间就增长到100%了，怀疑是内存泄漏，查了一下，果然是weblogic的bug。而且GC11g的安装文档上已经明确要求安装weblogic的相关patch了。

http://download.oracle.com/docs/cd/E11857_01/install.111/e15838/install_em_exist_db.htm#CIAIEAAC

Oracle WebLogic Server Patch Requirements

Ensure that you apply patch ID WDJ7 on Oracle WebLogic Server using the Oracle Smart Update utility. This patch fixes bugs 8990616, 9100465, and 9221722.

For information on applying this patch, see My Oracle Support note 1072763.1.

For information on Oracle Smart Update utility, see Oracle Smart Update Installing Patches and Maintenance Packs documentation available at:

http://www.oracle.com/technology/products/weblogic/index.html

How to apply recommended WLS patches on WLS home for 11g Grid Control Install/Upgrade [ID 1072763.1]

如何在Windows平台用Cygwin支持SSH来做Agent Push

Romeo — Thu, 03 Jun 2010 08:01:23 +0000

大家都知道在win平台上默认是不支持SSH的，而通过GC的GUI来给target主机安装agent（也叫agent push）是必须要用SSH的，因此必须得在windows上装一个工具Cygwin。下面是详细步骤

1：安装cygwin 之前必须确保系统中没有类Unix工具(如OpenSSH,MKSNT)，环境变量里没有OpenSSH\bin或者mksnt类似的项目。

定义安装目录 C:\cygwin，强烈建议安装在这个默认路径，如果Cygwin没有安装在此目录，需要编辑 $OMS_INSTANCE_HOME/sysman/prov/resources/ssPaths_msplats.properties来指向你安装的目录。

注意：如果在目标机上没有将Cygwin安装在C:\cygwin，那么你也需要将OMS机上的Cygwin安装在同一目录。Cygwin的安装路径中不能有空格。

选择 zip,unzip,openSSH,openSSL,vim, 点此 “skip” 使之变成选中，cywin会自动下载选择的软件包和它们依赖的包，并进行安装

2：编辑C:\cygwin\cygwin.bat，加入环境变量CYGWIN=binmode tty ntsec

set CYGWIN=binmode tty ntsec
C:
chdir \cygwin\bin
bash –login -I

3：打开cygwin控制台cygwin.bat，输入ssh-host-config

一开始几个都是yes，下面的是这么选

*** Query: Do you want to use a different name? (yes/no) no
*** Query: Create new privileged user account ‘cyg_server’? (yes/no) yes

然后输入密码

提示CYGWIN值时，输入binmode tty ntsec

Enter the value of CYGWIN for the daemon: [] binmode tty ntsec

回车

如果提示Problem with /var directory. Exiting. 一般是/var没有执行权限，chmod 775 /var就行了

4：生成SSH key

输入ssh-user-config，除了passphrase的地方是直接回车之外别的都是一路yes

5：net start sshd就能启动ssh了，或者在系统工具->服务里面启动

Metalink上有篇设置的详细文档

How to Install/Configure Cygwin and ‘ssh’ Server on Windows for use with Grid Control Remote’s Agent Deployment [ID 389632.1]

为实现EM中CRS rolling upgrade如何设置sudo以及sudo环境变量

Romeo — Tue, 29 Sep 2009 07:39:00 +0000

今天在EM dbconsole 11.2环境里给11gR2的CRS打rolling patch时碰到不少关于sudo的问题，特此记录以免忘记。

因为EM都是通过Agent来进行操作的，所有不可能拥有root权限，而打有些patch的时候又不得不用root权限，所以有必要为grid（Grid Infra的user，就是以前的Clusterware），oracle(RAC database的user)两个用户设置sudo。下面以grid用户为例，说明一下。

首先，要编辑sudo，推荐使用visudo命令，而不要去修改/etc/sudoers的权限（默认是440，即只读）。
以root用户登录

[root@cdcjp64vm3 ~]# visudo

找到

root    ALL=(ALL)       ALL

这一行，在其下面添加

grid    ALL=(ALL)       NOPASSWD: ALL

注意一定要加NOPASSWD，因为EM是从web界面上直接操作，在其打patch过程中是没法人工输入密码的，当然在打patch之前会让你输入一次grid用户的密码，但是这个密码似乎不能存起来留到之后的交互过程中使用。

另外，找到

Defaults    env_keep

这个部分是使用sudo之后要保留的环境变量列表，默认里面是没有ORACLE_HOME的，在rolling upgrade里面有一步需要ORACLE_HOME环境变量，否则会提示让你设置ORACLE_HOME。改为如下：

Defaults    env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR \
                        LS_COLORS MAIL PS1 PS2 QTDIR USERNAME \
                        LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \
                        LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC\
                        LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \
_XKB_CHARSET XAUTHORITY ORACLE_HOME"

验证一下：

[grid@cdcjp64vm3 ~] sudo env|grep ORA
ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1

OK。现在这样设置就能给CRS打patch了。