Tag: Oracle11g

Database Control improved in Oracle 11g – 1

Leave a comment

在Oracle 10gR2 RAC中，如果我们在各个节点上用emctl start dbconsole命令启动database control console，那么在每个节点上都会启动console，而在Oracle11g中，则有所改善，该命令只会启动指定节点上的dbconsole，而在剩余节点上启动的则是Enterprise Manager agent。

Oracle官方的解释是：因为database control console会发起很多连接到数据库，那么如果是一个很多节点的RAC环境，比如说32节点或者64节点，那么就很可能超过数据库设定的最大连接数。

需要注意的是，如果数据库是从10gR2升级到11g的，那么之前配置的database control仍然会保留10gR2的模式，也就是仍然会启动多个dbconsole，需要通过emca命令进行修改。

假设现在的RAC环境是：8节点的RAC，hostname分别是node1 ~ node8，SID分别是oradb1 ~ oradb8。

我们要实现，将dbconsole运行在node1和node5上，然后node1到node4上agent收集的信息发送到node1的dbconsole中，node5到node8上agent收集的信息发送到node5的dbconsole中。

emca -reconfig dbcontrol -cluster -EM_NODE node1 -EM_SID_LIST oradb2,oradb3,oradb4
emca -reconfig dbcontrol -cluster -EM_NODE node5 -EM_SID_LIST oradb6,oradb7,oradb8

使用下面的命令查看当前的cluster配置情况：

emca -displayConfig dbcontrol -cluster

emca命令的使用方法现在放入Utilities文档中了 – 11gR1的版本。

Why VKTM background process in Oracle 11g

8 Comments

在Oracle11g中，我们可以发现一个新的基础后台进程叫做VKTM （virtual keeper of time），这个进程是必须存在的。

在数据库启动时候的告警日志中可以看到：
VKTM started with pid=3, OS id=2256 at elevated priority
VKTM running at (20)ms precision

在数据字典中也可以查询到如下信息：


SQL> select name,description from v$bgprocess where name=’VKTM’;

NAME DESCRIPTION
—– —————————————–
VKTM Virtual Keeper of TiMe process

阅读Concepts文档可以看到对这个后台进程的解释是：

VKTM (virtual keeper of time) is responsible for providing a wall-clock time (updated every second) and reference-time counter (updated every 20 ms and available only when running at elevated priority).

我想这个解释仍然不足以描述这个进程到底是做什么的。

好吧，那这个进程到底是做什么的？

在11g之前所有的Oracle数据库后台或者前台进程如果需要获得当前时间信息，就需要调用操作系统的gettimeofday()函数或者说是相类似的函数。而VKTM进程就是专门用来获得时间信息然后将信息存放在SGA中供其它进程使用，这样其它进程当需要时间信息的时候，只要到SGA的某个内存位置去获得就好，而不用频繁调用gettimeofday()函数。毫无疑问，这样效率会更高。

在RAC测试中，Oracle 1.1.0.6版本LMSx进程获取时间信息时，可以从VKTM进程中获益大概70%的速度提升，而11.1.0.7将会更高。

同时，因为gettimeofday()函数也引发了很多bug，所以无论是RAC还是NORAC库，都将从VKTM进程中获益。

Oracle 11g new feature – Virtual Column

3 Comments

在之前的一篇 – Oracle 11g New Feature – Partition 文章中曾经提到虚拟列的概念，但是当时自己也有些疑问，今天在Oracle 11.1.0.6 上简单测试了一下。

CREATE TABLE tb_v
(col_1 number(6) not null,
col_2 number not null,
col_v as (col_1+col_2));

— 由于虚拟列的存在，所以即使指定了全部的实际列的值也会报值不足的错误
SQL> insert into tb_v values(1,2);

insert into tb_v values(1,2)

ORA-00947: not enough values

— 虚拟列中不允许显示插入值
SQL> insert into tb_v values(1,2,4);

insert into tb_v values(1,2,4)

ORA-54013: INSERT operation disallowed on virtual columns

–必须明确指定列名，才能正常插入数据
SQL> insert into tb_v(col_1,col_2) values(1,2);

1 row inserted

–检索表，已经自动计算虚拟列的值
SQL> select * from tb_v;

COL_1 COL_2 COL_V
——- ———- ———-
1 2 3

–选取该行ROWID
SQL> select rowid from tb_v;

ROWID
——————
AAAEdcAAEAAAC3/AAA

— 获得该行数据存放得到数据文件号
SQL> select dbms_rowid.rowid_relative_fno(row_id => ‘AAAEdcAAEAAAC3/AAA’) from dual;

DBMS_ROWID.ROWID_RELATIVE_FNO(
——————————
4

–获得该行数据存放的block号
SQL> select dbms_rowid.rowid_block_number(row_id => ‘AAAEdcAAEAAAC3/AAA’) from dual;

DBMS_ROWID.ROWID_BLOCK_NUMBER(
——————————
11775

— Dump这个数据块
SQL> alter system dump datafile 4 block 11775;

System altered

下面是dump内容的节选，可以看到确实只保存了两个字段，也就是虚拟列的值并没有存储在block中

block_row_dump:
tab 0, row 0, @0x1f8f
tl: 9 fb: –H-FL– lb: 0x1 cc: 2
col 0: [ 2] c1 02
col 1: [ 2] c1 03
end_of_block_dump

继续在虚拟列上创建索引，然后再看看索引的存储是否有不一样的地方。

SQL> create index idx_v on tb_v (col_v);

Index created

— 获得索引存储的文件号和block号
SQL> exec show_space(p_segname_a => ‘idx_v’,p_type_a => ‘INDEX’);

Total Blocks……………………….8
Total Bytes………………………..65536
Unused Blocks………………………4
Unused Bytes……………………….32768
Last Used Ext FileId………………..4
Last Used Ext BlockId……………….11777
Last Used Blocks……………………4
Last Used BlockId…………………..11780
FIRST LEVEL BITMAP BLOCK…………….11777
SECOND LEVEL BITMAP BLOCK……………11778
PAGETABLE SEGMENT HEADER…………….11779
FIRST Trans Data BLOCK………………11780
Dump SQL: alter system dump datafile 4 block 11780;

Dump 索引块，下面是Dump内容的节选，c1 04就是3，因此可见在创建索引的时候，Oracle会先去计算虚拟列的值，然后再根据结果创建索引。
row#0[8024] flag: ——, lock: 0, len=12
col 0; len 2; (2): c1 04
col 1; len 6; (6): 01 00 2d ff 00 00
—– end of leaf block dump —–

实际上基于虚拟列的索引就是一个函数索引，可以从DBA_INDEXES.FUNCIDX_STATUS=’ENABLED’这个条件得到验证。

其它的一些测试可以参看Oracle11g新特性：虚拟列virtual column from Ningoo。

下一篇计划测试虚拟列的性能。