星期三 十二月 31, 2014

只对某个特定的SQL语句开启10046 trace

最近碰到了这样一个有趣的问题: 有一条SQL语句,大部分时间它的执行时间是几十个毫秒; 但是偶尔某次的执行时间会长于2秒钟。因为应用对这个语句的执行时间非常的敏感,我们必须诊断是因为什么原因导致它偶尔执行时间长于2秒。


这个问题为什么会有挑战性呢?因为我们很难收集慢的时候的10046 trace:首先我们不知道这个问题什么时候会发生,也不知道会在哪个session里发生。如果对所有的session全天开启10046 trace, 会产生很多比较大的trace并影响数据库整体的性能。


好在这个数据库是11g的,在11gevent++的特性允许我们只对某个特定的SQL收集10046 trace. 即在运行这条SQL时开启10046 trace,在这条SQL运行完之后关闭10046 trace.这样可以显著的降低生成的trace的大小。但是因为我们无法确定哪个session会产生问题,所以只要运行过这个SQLsession都会产生一个trace文件。


开启的步骤是(要把下面的awsh60c8mpfu1替换成那条SQLSQL_ID)


alter system set events 'sql_trace [sql: awsh60c8mpfu1] level 12';


而关闭的步骤是(要把下面的awsh60c8mpfu1替换成那条SQLSQL_ID)


alter system set events 'sql_trace [sql: awsh60c8mpfu1] off';


在收集到很多10046 trace,并使用tkprof格式化后(需指定AGGREGATE=NO,这样tkprof会对每一次执行都生成汇总报告),我们最后定位到了问题发生时SQL语句读取物理块时花费了更多的时间。


关于这个主题,如果有后续的问题欢迎点击链接参与我们在中文社区的讨论。 




星期四 十二月 04, 2014

几种常见的library cache lock产生的原因


常见的library cache lock产生的原因在《高级OWI与Oracle性能调查》这本书和下面这个文档中有一般性的描述:
Troubleshooting Library Cache: Lock, Pin and Load Lock (Doc ID 444560.1)

一般可以理解的是alter table或者alter package/procedure会以X模式持有library cache lock,造成阻塞。
但是常见的问题还有以下几种原因:

1)错误的用户名密码:

一般需要通过ASH或者SSD/hang analyze去获取p3进行namespace分析。

             1.       event: 'library cache lock'
                time waited: 43 min 12 sec
                    wait id: 9               p1: 'handle address'=0x7000003117dfca0
                                             p2: 'lock address'=0x700000310866c80
                                             p3: '100*mode+namespace'=0x4f0003
             * time between wait #1 and #2: 0.000164 sec

<=================p3: '100*mode+namespace'=0x4f0003

mode=3
namespace=4f

HEX: 4f =>DEC: 79

select * FROM V$DB_OBJECT_CACHE;

SQL> select distinct KGLHDNSP,KGLHDNSD from x$kglob;

  KGLHDNSP KGLHDNSD
---------- ----------------------------------------------------------------
         0 SQL AREA
         4 INDEX
         1 TABLE/PROCEDURE
         3 TRIGGER
        52 SCHEDULER EARLIEST START TIME
        64 EDITION
        69 DBLINK
         2 BODY
        10 QUEUE
        79 ACCOUNT_STATUS
        23 RULESET
        24 RESOURCE MANAGER
        73 SCHEMA
        74 DBINSTANCE
        51 SCHEDULER GLOBAL ATTRIBUTE
        38 RULE EVALUATION CONTEXT
        82 SQL AREA BUILD
        75 SQL AREA STATS
         5 CLUSTER
        18 PUB SUB INTERNAL INFORMATION

<======79 ACCOUNT_STATUS

ACCOUNT_STATUS说明library cache lock是在account上,可能是用错误的用户名密码登录,或者是当时正有人alter user(这种几率极低)。

可以通过以下SQL去确认错误的用户名密码登录:
select username,
os_username,
userhost,
client_id,
trunc(timestamp),
count(*) failed_logins
from dba_audit_trail
where returncode=1017 and --1017 is invalid username/password
timestamp < sysdate -7
group by username,os_username,userhost, client_id,trunc(timestamp);

Or run following sql:
SELECT "USERNAME", "OS_USERNAME", "USERHOST", "EXTENDED_TIMESTAMP",returncode  FROM "SYS"."DBA_AUDIT_SESSION" WHERE returncode != 0;

当然必须确保audit 打开,并且有audit CREATE SESSION动作

To turn on audit:
Alter system set audit_trail=DB scope=spfile;
restart DB

audit CREATE SESSION;
audit ALTER USER;

检查:
show parameter audit_trail
select * from DBA_STMT_AUDIT_OPTS;

2)正在执行搜集统计信息,这是大家往往会忽略的,一般会看last_ddl_time,却忽略了last_analyzed,
检查脚本如下:

比如EMP是遇到library cache lock中的表名:
select owner,object_name,object_type,to_char(last_ddl_time,'yyyy-mm-dd hh24:mi:ss') from dba_objects where object_name='EMP';

select table_name,to_char(last_analyzed,'yyyy-mm-dd hh24:mi:ss') from dba_tables where table_name='EMP';

也需要检查所有dependency的对象,因为oracle对象是相互关联的,一个对象失效会导致一串失效。
select owner,object_name,object_type,to_char(last_ddl_time,'yyyy-mm-dd hh24:mi:ss') ddl_time from dba_objects where object_name in
(
select p.name
from sys.obj$ d, sys.dependency$ dep, sys.obj$ p
where d.obj# = dep.d_obj# and p.obj# = dep.p_obj#
start with d.name='EMP'
connect by prior dep.p_obj#=dep.d_obj#)
order by ddl_time desc;

select table_name,to_char(last_analyzed,'yyyy-mm-dd hh24:mi:ss') from dba_tables where table_name in
(
select p.name
from sys.obj$ d, sys.dependency$ dep, sys.obj$ p
where d.obj# = dep.d_obj# and p.obj# = dep.p_obj#
start with d.name='EMP'
connect by prior dep.p_obj#=dep.d_obj#)
order by last_analyzed desc;

比较典型的一个用户实例:
select to_char(last_analyzed,'yyyy-mm-dd hh24:mi:ss') from dba_tables where table_name='XXXXX';
--2014-11-25 16:52:50
<=============gathering statistics in the issue time

2014-11-25 16:52:52 16620 c34q5c8gf6kum library cache lock
2014-11-25 16:52:52 16643 c34q5c8gf6kum library cache lock
<======The issue starts from 16:52:52 while statistics was gathered at 16:52:50

3)错误的语句解析(failed parse)
这是通常很难注意到的一个问题,因为被解析的语句往往在AWR中找不到(因为没有通过parse),要注意查看AWR中的“failed parse elapsed time”

Event Waits Time(s) Avg wait (ms) % DB time Wait Class
library cache lock 6,714,208 363,093 54 67.14 Concurrency
library cache: mutex X 11,977,886 99,050 8 18.31 Concurrency
DB CPU   38,971   7.21 
db file sequential read 350,069 2,465 7 0.46 User I/O
log file sync 217,673 1,969 9 0.36 Commit


Statistic Name Time (s) % of DB Time
sql execute elapsed time 537,418.09 99.37
parse time elapsed 467,101.99 86.37
failed parse elapsed time 460,663.79 85.18 <===============failed parse elapsed time was high. That means the issue was caused by parse failed.

详细请参考:
High Waits for 'library cache lock' and 'library cache: mutex X' Due to Parse Failures When Using JDBC ResultSet.TYPE_SCROLL_SENSITIVE (Doc ID 1566018.1)



参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"分享:几种常见的library cache lock产生的原因"。 


了解更多博文信息请访问Oracle数据库产品技术支持-博客文章索引


星期五 十一月 14, 2014

TimesTen 常见问题答疑(科普篇)

什么是Oracle TimesTen 内存数据库?

Oracle TimesTen内存数据库是一款内存优化的关系型数据库。
该产品可使应用大幅提高响应速度和吞吐量来满足当今有实时需求的企业,
尤其适合电信,金融,互联网,旅游,在线游戏,保险等行业的企业。
部署在应用层的TimesTen数据库是一款可嵌入式或者独立的数据库。
它完全驻留在物理内存中,通过标准SQL接口进行数据库操作。
此外,该产品还包括复制技术来进行实时事务在TimesTen数据库之间的复制,
进而实现高可用性和分担负载的目的。

-----------
什么是Oracle TimesTen 应用层数据库缓存?

自从Oracle 12c 数据库推出了In-Memory功能,为了避免理解上的误解,将之前的 Im-Memory Database Cache 改为了应用层数据库缓存。
该功能是 Oracle TimesTen 数据库的一个选项,来提供实时的 对Oracle 数据库的读写缓存。
通过缓存性能敏感的表的子集从Oracle数据库到应用层,来提高应用事务响应时间。
缓存表在TimesTen数据库中的管理仍然是常规的关系型数据库表的管理方式。因此,可以提供给应用一个完全通用和功能完备的关系型数据库,与Oracle数据库保持缓存透明维护的一致,并且实时高效的内存数据库。
为了实现高可用性,Orale TimesTen 应用层数据库缓存可以通过使用actinve-standby配置的部署方案,且缓存表可以在Oracle TimesTen数据库之间进行实时复制。

-----------
TimesTen 内存数据库是否是 Oracle 12c数据库的一部分?

Oracle TimesTen 应用层数据库缓存是针对 Oracle 12c 和 11g数据库的一个数据库功能。它包括了TimesTen 内存数据库和缓存技术。可以使得TimesTen 作为一个内存缓存数据库自动将数据在TimesTen 和 Oracle 数据库同步。
Oracle TimesTen内存数据库需要单独购买License。包括TimesTen 内存数据库和复制组件。
-----------

TimesTen 数据库有哪些大小限制么?

数据库的大小受限于服务器上的物理内存大小。
在32位平台,受限于32位地址空间,因此数据库大小在2GB以内,或者更小,取决于具体平台。
对于64位平台,除了机器上的物理内存大小外,没有其他大小限制。
现有的用户在部署数据库的大小方面,从1GB 到超过2TB均有实际案例。
-----------

哪些应用最适合运行TimesTen?

TimesTen 被用在众多电信应用系统中,例如认证授权,计费,呼叫中心等。
也同样可以部署在金融应用系统中,例如安全贸易,反欺诈,股票证券,网上银行等方面。
其他应用系统包括游戏公司,CRM系统,飞机订票系统,旅游运输,国防应用系统等。

-----------
Oracle TimesTen技术都可以运行在哪些平台上?

以下列出的是当前支持的平台:
Linux x86, Linux x64, Solaris SPARC 64位,Solaris SPARC 32位客户端,Windows x64, Windows x86,
IBM AIX on POWER System 64位, IBM AIX on POWER System 32位客户端 以及 Solaris x64位。
Oracle TimesTen应用层数据库缓存功能支持 Oracle 数据库12c, 11gR2 和 11gR1。


-----------


如何获得 TimesTen 最新的小版本信息?


请参考实时更新的官方文档: TimesTen 内存数据库 (IMDB) 版本支持摘要 (Doc ID 1536728.1)


-----------

TimesTen 内存数据库可以独立作为数据库运行么?

当然。TimesTen 内存数据库被很多客户在应用层作为独立数据库来进行使用。
TimesTen对SQL操作提供全方位的事务支持,且事务日志保留在硬盘上用作恢复(数据库始终保留在内存中)。

-----------
数据是通过什么API来连接到TimesTen 内存数据库?

TimesTen内存数据库支持标准的ODBC, JDBC接口,并且还有针对应用的ADO.NET和OCI接口来连接数据库,使用标准的SQL-92。

-----------
TimesTen应用开发都使用哪些用语言?

可以使用Java, .NET, C, C++, Pro*C 和 PL/SQL来进行应用开发。
可以参考官方文档来获得程序样本。
http://www.oracle.com/technetwork/database/database-technologies/timesten/documentation/index.html
-----------

什么是嵌入式模式?

TimesTen内存数据库最初就是设计并优化运行在应用层。 数据库可以直连,即 嵌入到应用系统来优化性能。
TimesTen嵌入到应用中,SQL访问无需考虑网络或者IPC的负载问题。即便运行在嵌入式模式下,
TimesTen 仍旧提高完全的多进程,多线程访问和并行控制能力。
-----------
TimesTen 内存数据库是否支持类似Oracle 数据库的索引?

当然。TimesTen内存数据库支持索引。索引会提高数据库查询的性能,这点与Oracle 数据库没有区别。
TimesTen当前版本支持三种类型的索引:
区域查询,来提高相等或者不等区间查询;
哈希索引,提高主键和等效访问优于区域查询;
位图查询索引,用于没有太多唯一值查询和低并发下DML事务处理。
-----------
TimesTen 对软硬件有特殊要求么?

首先,TimesTen的设计都是基于数据驻留内存RAM管理的前提。
因此,最重要的是要考虑在应用服务器端,硬件是否仍有足够的内存。
除此之外,没有太多对硬件的要求。
作为任何一款应用产品,有足够数量的CPU(运行在适当的时钟速度下)也是确保应用运行速度的关键
为了利用多CPU的硬件条件,你需要或者运行多个应用,或者将你的应用写成多线程运行。
另外,事务日志和检查点文件是存储在硬盘上。因此,更快的磁盘表现也会提高整体性能。
TimesTen的Cache功能部署在应用层,通过SQL*Net与Oracle 数据库通信。
Oracle即时客户端因此需要安装在TimesTen Cache端,来连接Oracle 数据库。
-----------
数据结构的设计和创建在TimesTen 中是如何实现的?

TimesTen 支持标准SQL。创建数据结构一般使用SQL DDL语句,例如:
CREATE TABLE, CREATE INDEX, CREATE SEQUENCE, CREATE VIEW, CREATE MATERIALIZED VIEW, CREATE PACKAGE, CREATE PROCEDURE, CREATE FUNCTION, CREATE SYNONYM, ALTER TABLE 等。
这种设计均基于关系型数据库。在TimesTen中设计和管理数据库比基于磁盘优化的关系型数据库更加简单,因为它无需考虑表的扩展大小或者磁盘碎片整理等因素。
-----------
当节点宕机,由于是内存数据库,TimesTen是如何恢复的?

当整个数据库驻留内存时,TimesTen 仍旧有事务日志和检查点文件存放在磁盘上。当系统重启或者意外宕机,内存数据库可以从检查点文件和事务日志中得到恢复。另外,用户还可以通过配置复制技术来提高高可用性。
-----------
TimesTen 应用层数据库缓存在哪些平台可以被支持?

TimesTen 应用层数据库缓存对于Oracle数据库服务器来说,作为一个客户端应用程序。TimesTen 应用层数据库缓存与TimesTen 内存数据库所支持的平台相同。
-----------
是否可以将TimesTen 应用层数据库缓存允许在与Oracle数据库不同的操作系统平台?

当然可以。因为TimesTen 应用层数据库缓存是作为Oracle客户端来运行的。可以运行在与Oracle 数据库服务器不同
的平台。一般来说TimesTen 应用层数据库缓存运行在应用层,而Oracle数据库运行在企业架构的数据库层。
-----------
如果Oracle 数据库是一个TB级别的数据库,我的TimesTen 应用层数据库缓存应该设置多大?

性能敏感的数据量多少需要被缓存到TimesTen数据库完全取决应用的设计。除了可以缓存整个数据库,数据库表,列,以及行的子集都可以被缓存到TimesTen。另外一个选择,可以定义一个动态缓存,数据来自Oracle数据库中的表,且按需加载。
-----------
什么是TimesTen 复制?

TimesTen 复制是TimesTen 内存数据库和TimesTen 应用层数据库缓存的一个组件。TimesTen复制技术可以在TimesTen 服务器之间实现实时数据复制。用于创建高可用性的架构,容灾站点,在多节点分布数据。复制技术支持active/standby 或者 active/active的配置,使用同步或者异步的数据传输机制。
-----------
TimesTen复制如何保证在系统宕机时的数据可持续性?

TimesTen复制可以配置为整个数据库级别的复制到一个或多个TimesTen节点。
在一次failover后,备节点变为主节点。而发生问题的节点可以从新的主节点得到恢复。
-----------
是否可以复制选定的数据库表?

当然可以。表级别的复制和数据库级别的复制都是支持的。
-----------
TimesTen复制支持什么样的网络协议?

TimesTen 复制在复制的节点之间通过LAN或者WAN,使用的是TCP/IP socket。
-----------
TimesTen 的复制是否可以是双向的?

当然。单向和双向复制都是支持的。对于双向复制来说,建议负载要平均来避免可能发生的大量冲突。一旦复制冲突发生,即,更新同一个数据库的行,TimesTen复制支持基于时间戳的冲突检测和解决。
-----------

星期二 十月 21, 2014

在Linux上如何为TimesTen数据库设置hugepage

第一步,检查shmmax设置,使其大于需要设置的huge page的大小:
[root@nascds8 ~]# vi /etc/sysctl.conf


fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576


# /sbin/chkconfig boot.sysctl on
# /sbin/sysctl -p


cat /proc/sys/kernel/shmmax
4294967295


第2步,设置vm.hugetlb_shm_group


cd $TT_HOME
ls -l
drwxr-xr-x 4 oracle ttadmin   4096 Jan 26  2013 3rdparty
drwxr-xr-x 2 oracle ttadmin   4096 Aug 28 16:06 bin
drwxr-xr-x 3 oracle ttadmin   4096 Dec  1  2012 include
drwxr-xr-x 2 oracle ttadmin  69632 Sep  9 04:20 info
drwxr-xr-x 2 oracle ttadmin   4096 Jul 12 10:28 java


<=======TimesTen安装在ttadmin组下
-bash-3.2$ id -a
uid=501(oracle) gid=511(ttadmin) groups=501(oinstall),502(dba),504(asmadmin),506(asmdba),511(ttadmin)


<========ttadmin组的id为511
[root@nascds8 ~]# cat /proc/sys/vm/hugetlb_shm_group
0
# echo 511 > /proc/sys/vm/hugetlb_shm_group
<=======将511组写入 /proc/sys/vm/hugetlb_shm_group


vi /etc/sysctl.conf
vm.hugetlb_shm_group=511
vm.nr_hugepages=1034    <=======hugepage的个数,每个是2M。


第3步,设置memlock(max locked memory)


vi /etc/security/limits.conf


@ttadmin soft memlock unlimited
@ttadmin hard memlock unlimited


ulimit -l unlimited
ulimit -a



第4步,设置linuxLargePageAlignment为2
cat /proc/meminfo  | grep Huge
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB


vi ttendaemon.options
-linuxLargePageAlignment 2


第5步,启动TimesTen数据库,检查是否使用Hugepage,以及是否需要调整vm.nr_hugepages:
ipcs -a
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0bf7d308 2752517    grid      660        4096       0
0xd4105d4c 3145734    oracle    660        211812352  27
0x00000000 3506192    oracle    660        4096       0
0x00000000 3538961    oracle    660        4096       0
0xdae1e6c4 3571730    oracle    660        4096       0
0x28008086 3604499    oracle    666        1048576    1
0x55000033 3702804    oracle    666        1048576    1


ttIsql -connstr "dsn=mk_rep_db1"


connect "dsn=mk_rep_db1";
Connection successful: DSN=mk_rep_db1;UID=oracle;DataStore=/home/oracle/TimesTen/tt1121/info/mk_rep_db1;DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;LogFileSize=32;DRIVER=/home/oracle/TimesTen/tt1121/lib/libtten.so;PermSize=900;TempSize=900;TypeMode=0;PLSQL_MEMORY_SIZE=16;PLSQL_MEMORY_ADDRESS=0x14000000;CacheGridEnable=0;OracleNetServiceName=R1120;LogBufMB=32;
(Default setting AutoCommit=1)
Command>


--ipcs -a
key        shmid      owner      perms      bytes      nattch     status
0x0bf7d308 2752517    grid      660        4096       0
0xd4105d4c 3145734    oracle    660        211812352  27
0x00000000 3506192    oracle    660        4096       0
0x00000000 3538961    oracle    660        4096       0
0xdae1e6c4 3571730    oracle    660        4096       0
0x28008086 3604499    oracle    666        1048576    1
0x55000033 3702804    oracle    666        1048576    1
0x02000107 3735573    oracle    666        1933422144 2 <============Here
0x03000107 3768342    oracle    666        16777216   2


1933422144/2048/1024=922


或者运行一个脚本hugepages_settings.sh来计算合适的hugepage大小:


-bash-3.2$ . ./hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 1034


第6步,根据建议调整vm.nr_hugepages的大小:
vi /etc/sysctl.conf
vm.nr_hugepages=1034
/home/oracle/TimesTen/tt1121/bin/ttDaemonAdmin -stopserver
reboot


cat /proc/meminfo | grep Huge
HugePages_Total:  1034
HugePages_Free:    901
HugePages_Rsvd:    898               <=====used
Hugepagesize:     2048 kB



---------------
example:



-bash-3.2$ cat /proc/meminfo | grep Huge
HugePages_Total:  1034
HugePages_Free:    906
HugePages_Rsvd:    253  <=========
Hugepagesize:     2048 kB



Data store /home/oracle/TimesTen/tt1121/info/master1
There are 10 connections to the data store
Shared Memory KEY 0x12000105 ID 2883592 (LARGE PAGES, LOCKED)<===========2883592 LARGE PAGES, LOCKED
PL/SQL Memory KEY 0x13000105 ID 2916361 Address 0x26000000
Type            PID     Context     Connection Name              ConnID
Subdaemon       11782   0x09686340  Manager                        2032
Subdaemon       11782   0x096d8e98  Rollback                       2033
Subdaemon       11782   0x097a3f98  Flusher                        2034
Subdaemon       11782   0x097f4d98  HistGC                         2041


-bash-3.2$ ipcs -a


------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0bf7d308 2752517    grid      660        4096       0
0xd4105d4c 2981894    oracle    660        211812352  23
0x55000033 2850823    oracle    666        1048576    1
0x12000105 2883592    oracle    666        570425344  1      <===========2883592
0x13000105 2916361    oracle    666        16777216   1
0x1656e538 3014666    oracle    640        169869312  18


从内存中卸载数据库:
-bash-3.2$ ttadmin -ramunload master1
RAM Residence Policy            : manual
Manually Loaded In RAM          : False
Replication Agent Policy        : manual
Replication Manually Started    : False
Cache Agent Policy              : manual
Cache Agent Manually Started    : False


内存被释放了:
-bash-3.2$ ipcs -a


------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0bf7d308 2752517    grid      660        4096       0
0xd4105d4c 2981894    oracle    660        211812352  23
0x55000033 2850823    oracle    666        1048576    1
0x1656e538 3014666    oracle    640        169869312  18



HugePages_Total:  1034
HugePages_Free:    935
HugePages_Rsvd:      2
Hugepagesize:     2048 kB



参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"分享:在Linux上如何为TimesTen数据库设置hugepage"。 


了解更多博文信息请访问Oracle数据库产品技术支持-博客文章索引

星期二 十月 14, 2014

使用error stack 抓取存储过程的当前SQL

正常情况下,SQL的性能问题应该使用10046 trace进行分析,但是对于正在运行的存储过程,你却无法知道它卡在哪一步上了。
因为从v$session中只能看到最外层的存储过程执行,从10046看,因为prase阶段已经过去,也无法抓到当前的SQL语句。
以下介绍一个通过error stack分析正在运行的存储过程的实例。

对于一个正在运行的进程取errorstack和10046 trace:

sqlplus / as sysdba
oradebug setospid  14227
oradebug unlimit
oradebug Event 10046 trace name context forever, level 12
oradebug dump errorstack 3
<wait 1 minute>
oradebug dump errorstack 3
oradebug Event 10046 trace name context off;
oradebug tracefile_name

Format your 10046 trace file:
$tkprof <trace file> <output file>

For example:
$cd /u01/OracleAPP/oracle/admin/R1020/udump
$ls -ltr
$tkprof r1020_ora_14227.trc 14227.output

以下拿error stack输出做例子:
当前SQL还是最外层的调用:
*** 2014-09-29 11:19:01.723
ksedmp: internal or fatal error
Current SQL statement for this session:
call test(:1,:2,:3);



session当前正在执行的语句,也还是最外层的调用:
 SO: c000000cf3d469a0, type: 4, owner: c000000cf3aff038, flag: INIT/-/-/0x00
    (session) sid: 2154 trans: c000000cd6f2e558, creator: c000000cf3aff038, flag: (8100041) USR/- BSY/-/-/-/-/-
              DID: 0001-0E13-00C964B6, short-term DID: 0000-0000-00000000
              txn branch: c000000ccc19da48
              oct: 170, prv: 0, sql: c000000cfdbef790, psql: c000000cf8911380, user: 81/CRM_APP

<=====sql: c000000cfdbef790

      LIBRARY OBJECT LOCK: lock=c000000bf08347f0 handle=c000000cfdbef790 mode=N
      call pin=0000000000000000 session pin=0000000000000000 hpc=0000 hlc=0000
      htl=c000000bf0834870[c000000bf029f4e8,c000000c0fd03380] htb=c000000be508fd68 ssga=c000000be508fb30
      user=c000000cf3d469a0 session=c000000cf3d469a0 count=1 flags=[0000] savepoint=0x54223b5e
      LIBRARY OBJECT HANDLE: handle=c000000cfdbef790 mtx=c000000cfdbef8c0(1) lct=422374 pct=1 cdp=1
      name=call test(:1,:2,:3);

这时,我们在此文件中使用关键字"cursor pin"查询(因为正在被执行的cursor是被pin住的):

KGX Atomic Operation Log c000000c46c068b8
       Mutex c000000cb0bb3c50(0, 4) idn d1fc642e oper SHRD
       Cursor Pin uid 2154 efd 0 whr 5 slp 0
       opr=4 pso=c000000be618afd0 flg=0
       pcs=c000000cb0bb3c50 nxt=0000000000000000 flg=18 cld=0 hd=c000000cf96a06c8 par=c000000c59a406d8
       ct=1 hsh=0 unp=0000000000000000 unn=0 hvl=b0bb43f0 nhv=0 ses=0000000000000000
       hep=c000000cb0bb3cd0 flg=80 ld=1 ob=c000000c38ab25f8 ptr=c000000c16e28c18 fex=c000000c16e27f28
      ----------------------------------------
      SO: c000000cbbad7cc0, type: 53, owner: c000000cf3d469a0, flag: INIT/-/-/0x00
      LIBRARY OBJECT LOCK: lock=c000000cbbad7cc0 handle=c000000cf9f2bb00 mode=N
      call pin=0000000000000000 session pin=0000000000000000 hpc=0000 hlc=0000
      htl=c000000cbbad7d40[c000000c0f625548,c000000be618b050] htb=c000000be508ff28 ssga=c000000be508fb30
      user=c000000cf3d469a0 session=c000000cf3d469a0 count=1 flags=[0000] savepoint=0x54223b5f
      LIBRARY OBJECT HANDLE: handle=c000000cf9f2bb00 mtx=c000000cf9f2bc30(1) lct=2203 pct=125 cdp=1
      name=
SELECT * from test where c1= :B1 and c2=:B2 and C3=:B3
      hash=ac2274f043d741eddeab7ad9d1fc642e timestamp=09-18-2014 21:06:00

<=====找到你了。handle=c000000cf9f2bb00。

       Cursor Pin uid 2154 efd 0 whr 4 slp 0
       opr=4 pso=c000000c0fd03300 flg=0
       pcs=c000000cbabfc900 nxt=0000000000000000 flg=18 cld=0 hd=c000000cfdbef608 par=c000000cbabfd330
       ct=0 hsh=0 unp=0000000000000000 unn=0 hvl=babfd160 nhv=0 ses=0000000000000000
       hep=c000000cbabfc980 flg=80 ld=1 ob=c000000cbabfc510 ptr=c000000ca7f764e8 fex=c000000ca7f757f8
      ----------------------------------------
      SO: c000000bf08347f0, type: 53, owner: c000000cf3d469a0, flag: INIT/-/-/0x00
      LIBRARY OBJECT LOCK: lock=c000000bf08347f0 handle=c000000cfdbef790 mode=N
      call pin=0000000000000000 session pin=0000000000000000 hpc=0000 hlc=0000
      htl=c000000bf0834870[c000000bf029f4e8,c000000c0fd03380] htb=c000000be508fd68 ssga=c000000be508fb30
      user=c000000cf3d469a0 session=c000000cf3d469a0 count=1 flags=[0000] savepoint=0x54223b5e
      LIBRARY OBJECT HANDLE: handle=c000000cfdbef790 mtx=c000000cfdbef8c0(1) lct=422374 pct=1 cdp=1
      name=call test(:1,:2,:3);

<====当然还有最外层这个cursor

       Cursor Pin uid 2154 efd 0 whr 5 slp 0
       opr=4 pso=c000000c0ffd6730 flg=0
       pcs=c000000cb5fbe988 nxt=0000000000000000 flg=18 cld=0 hd=c000000cf7faf950 par=c000000cb5fbf3b8
       ct=0 hsh=0 unp=0000000000000000 unn=0 hvl=b5fbf1e8 nhv=0 ses=0000000000000000
       hep=c000000cb5fbea08 flg=80 ld=1 ob=c000000cb5fbe598 ptr=c000000cb5fbb710 fex=c000000cb5fbaa20
      ----------------------------------------
      SO: c000000be6194b10, type: 53, owner: c000000cf3d469a0, flag: INIT/-/-/0x00
      LIBRARY OBJECT LOCK: lock=c000000be6194b10 handle=c000000cf7fafb80 mode=N
      call pin=0000000000000000 session pin=0000000000000000 hpc=0000 hlc=0000
      htl=c000000be6194b90[c000000be508ffe8,c000000c0ffd67b0] htb=c000000be508ffe8 ssga=c000000be508fb30
      user=c000000cf3d469a0 session=c000000cf3d469a0 count=1 flags=[0000] savepoint=0x54223a54
      LIBRARY OBJECT HANDLE: handle=c000000cf7fafb80 mtx=c000000cf7fafcb0(0) lct=17870500 pct=1 cdp=1
      name=table_1_ff_159_0_0_0
<====以及一些LIBRARY OBJECT对象(可以忽略)

使用关键字“sqltxt(c000000cf9f2bb00)”查询可以找到该cursor使用的绑定变量的值:

Cursor#37(9fffffffbf3b2828) state=ROW curiob=9fffffffbf340638
 curflg=c7 fl2=0 par=0000000000000000 ses=c000000cf3d469a0
 sqltxt(c000000cf9f2bb00)=
SELECT * from test where c1= :B1 and c2=:B2 and C3=:B3
  hash=ac2274f043d741eddeab7ad9d1fc642e
  parent=c000000c59a406d8 maxchild=01 plk=c000000cbbad7cc0 ppn=n
cursor instantiation=9fffffffbf340638 used=1411529567
 child#0(c000000cf96a06c8) pcs=c000000cb0bb3c50
  clk=c000000be618afd0 ci=c000000c38ab2710 pn=c000000c46c068b8 ctx=c000000c16e28c18
 kgsccflg=0 llk[9fffffffbf340640,9fffffffbf340640] idx=0
 xscflg=c0151476 fl2=5000001 fl3=402a210c fl4=100
 Bind bytecodes
  Opcode = 1   Unoptimized
  Offsi = 48, Offsi = 0
  Opcode = 1   Unoptimized
  Offsi = 48, Offsi = 32
  Opcode = 1   Unoptimized
  Offsi = 48, Offsi = 64
kkscoacd
 Bind#0
  oacdty=02 mxl=22(21) mxlc=00 mal=00 scl=00 pre=00
  oacflg=03 fl2=1206001 frm=00 csi=00 siz=176 off=0
  kxsbbbfp=9fffffffbeed1f40  bln=22  avl=04  flg=05
  value=10001
 Bind#1
  oacdty=02 mxl=22(21) mxlc=00 mal=00 scl=00 pre=00
  oacflg=03 fl2=1206001 frm=00 csi=00 siz=0 off=24
  kxsbbbfp=9fffffffbeed1f58  bln=22  avl=04  flg=01
  value=11409
 Bind#2
  oacdty=01 mxl=128(100) mxlc=00 mal=00 scl=00 pre=00
  oacflg=03 fl2=1206001 frm=01 csi=852 siz=0 off=48
  kxsbbbfp=9fffffffbeed1f70  bln=128  avl=09  flg=01
  value="222410641"

<=====当前使用的绑定变量的值。



参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"分享:使用error stack 抓取存储过程的当前SQL"。 


了解更多博文信息请访问Oracle数据库产品技术支持-博客文章索引


星期二 六月 03, 2014

Linux平台上配置Oracle ASMLib和磁盘多路径

配置Oracle ASMLIB和多路径磁盘


以下文档描述如何在linux的平台下使用oracle的asmlib来访问多路径的磁盘,无论您使用哪种多路径的软件,该文档是建立在已经创建好了多路径磁盘的基础上的。这个文档给出的多路径磁盘的名称是" multipatha",和存储厂商无关。


涉及多路径软件的问题:

在使用多路径软件的时候,我们有两个问题需要面对:ASM无法同时看到2次同样的磁盘,这样会出现错误。每块盘在多路径的配置下会出现至少3次,如:

磁盘的第一条路径


磁盘的第二条路径


由多路径软件聚合的逻辑路径



下面是一个例子:假设一个系统有一个本地磁盘,为/ dev/ sda上,和一个磁盘通过外部存储连接.该主机拥有2条链路或者路径来访问这个外部的存储。


Linux的SCSI驱动会看到所有的这两条路径。他们会显示成/dev/sdb和/dev/sdc.系统可以通过sdb或者sdc来访问到同样的终端。


此时,如果我们启用多路径的软件来管理,会有一条多路径软件聚合出来的磁盘 ,如/dev/multipatha,它能通同时访问到这两个路径,也就是说,任何I/ O使用multipatha可以通过任何一条路径来访问磁盘。如果一个系统使用sdb路径,而这条链路上的电缆被拔出时,系统会收到错误。但是multipath的磁盘会知道切换到sdc的路径上去继续工作。


大部分的软件是无法识别出来多路径的配置的,它可以使用任何一条路径:sdb或者sdc或者是multpatha,并且是无法知道有什么区别的。ASMLIB也一样,默认的配置中,ASMLIB也是不会关心使用那条路径的。


ASMLIB会选择,并且只会选择一条路径,因为ASM不能同时管理两块相同的磁盘。这样我们就解决了第一个问题。ASM只会看到一条路径,而且可以正常的工作。


这就出现了第二个问题:ASM究竟看到的是那个路径?


默认的情况下,ASMLIB会选择第一条它找到的路径.Linux系统中给出的第一条路径,第一条路径取决于磁盘的驱动,它可能是multipath 或者是某一条单路径。


系统管理员希望ASMLIB始终使用多路径的磁盘!如果Oracle不是使用它,有什么指定的方式吗?


答案是没有,尽管如此,如果我们想让ASMLIB知道多路径软件的磁盘看起来是什么样的,那么我们必须通过配置来告诉它:


磁盘扫描顺序:


    ASMLIB是通过ASMLIB安装中描述的过程来把磁盘标识成ASMLIB使用的磁盘。ASMLIB通过一个磁盘扫描的过程来知道哪些磁盘是被标识过的。ASMLIB每次启动的时候都会运行一次这样的扫描,当然系统管理员可以通过/etc/init.d/oracleasm scandisks的命令来强制做一次扫描。ASMLIB会检查系统中的每一块磁盘。它会检查每一块盘是否被标识成了asmlib的磁盘,所有被标识过的磁盘都是ASMLIB的有效盘,通常情况下,ASMLIB通过OS的列表顺序来检查这些磁盘,大部分的OS都能提供合理的顺序。


上边我们说的情况,我们描述了一种OS的顺序不够好的情况。系统管理员希望ASMLIB在看到单路径的盘之前先扫描到多路径的聚合磁盘。这样ASMLIB会选择多路径聚合出来的磁盘,并把它交给Oracle使用。


ASMLib允许两种修改方式来控制磁盘扫描的顺序。第一种,它允许我们排除一部分不需要扫描的磁盘。换句话说,ASMLib会完全忽略这些磁盘。第二种,系统管理员可以指定哪些磁盘先被扫描.指定的这些磁盘会在系统中其它磁盘扫描之前完成扫描。


    多路径软件配置中可以使用任意一种方式,系统管理员可以选择排除所有的单路径磁盘的方式,这样ASMLib会忽略他们,只扫描多路径的磁盘。或者系统管理员可以指定多路径的盘被先扫描。这样ASMLib就会先发现聚合路径的盘,优先选择先发现的磁盘。



配置扫描的顺序:


ASMLib的配置文件的路径在/etc/sysconfig/oracleasm.它被链接到文件/etc/sysconfig/oracleasm-_dev_oracleasm 工具会读取后边的这个文件。这里包含了所有系统管理员通过/etc/init.d/oracleasm configure 命令配置的启动配置信息,但是命令不能配置扫描的顺序。


该配置文件中包含很多配置的变量。我们可以使用以下2个:


ORACLEASM_SCANORDER 参数指定了哪些磁盘被优先扫描;


ORACLEASM_SCANEXCLUDE参数指定了哪些磁盘在扫描的过程中被忽略掉;


该变量用空格分隔的前缀字符串列表来匹配.换言之,如果一个磁盘的开始部分和前缀相同,那么就是匹配。例如,前缀字符串sd会匹配到所有的SCSI驱动的设备。注意不是模糊匹配.参数里不要使用通配符,他们是简单的前置字符。另外注意 /dev/ 路径并不是前置字符的一部分。


注意:当扫描的过程中,只有内核知道的设备名才会被扫描得到。当使用device-mapper的时候,内核看到的设备是/dev/dm-XX。在/dev/mapper/XXX中的设备名称是udev创建的其它可读性的名称。无论是ORACLEASM_SCANORDER 还是 ORACLEASM_SCANEXCLUDE必须使用 dm 前置字符。


以下是一些例子:


注意:如果我们手工的编辑/etc/sysconfig/oracleasm,一定确保不要破坏该文件到/etc/sysconfig/oracleasm-_dev_oracleasm的链接。


多路径磁盘优先读取:


系统管理员配置ASMLib来有限读取多路径软件的聚合盘,在ASMLib的配置文件中,编辑ORACLEASM_SCANORDER变量,如下格式:


ORACLEASM_SCANORDER="multipath sd"


此时,在扫描的过程中,ASMLib会首先寻找以"multipath"开头的磁盘。多路径的设备/dev/multipatha 当然是符合的。这样它就会被优先扫描到。然后ASMLib开始寻在以"sd"开头的磁盘。这些是SCSI的磁盘。本地设备/dev/sda会被扫描到,但是它并非一个ASM的磁盘。


单路径的磁盘/dev/sdb和/dev/sdc也会被扫描到,他们是ASM的磁盘,但是ASMLib 会发现已经有了一条通道来访问它。ASMLib会忽略他们。接下来ASMLib会继续扫描其它没有匹配前置字符的磁盘。




排除但路径的磁盘:



系统管理员可以配置ASMLib来忽略但路径的磁盘。在ASMLib的配置文件中,编辑ORACLEASM_SCANEXCLUDE变量,如下格式:


ORACLEASM_SCANEXCLUDE="sdb sdc"


这里,系统管理员做了一些配置。ASMLib会排除掉完全匹配的磁盘/dev/sdb和/dev/sdc.它不会忽略其他的SCSI磁盘。这样,ASMLib在扫描的过程中就会忽略这2块磁盘,仅仅会看到/dev/multipath的磁盘,同样,Oracle会使用多路径的磁盘。


EMC PowerPath 和ASMLib


很多系统管理员会使用EMC PowerPatch来做多路径和ASMLib的磁盘配置。


尽管如此,PowerPath和2.4 kernels EMC是不支持的。Linux系统2.6内核,如RHEL 4或者SLES 9以及2.0ASMLib kernel 驱动是支持的。


关于EMC Power Patch的使用,请参考EMC Support Matrix的文档来校验任何/所有 兼容性的需求是否满足。


如果您有任何关于 ASMLib 和 PowerPath 在Linux 2.4 Kernel上的使用,如RHEL3 SLES8 等平台上的疑问,请咨询EMC




注: 该文档翻译自OTN的官方链接:


Configuring Oracle ASMLib on Multipath Disks






星期一 三月 24, 2014

如何在各个平台上配置NTP的微调模式

对于11.2之前的版本,很多环境的重启原因(top5的情况)是由于NTP调整时间的步伐过大导致的,所以RAC环境中,我们建议用户如果使用NTP,需要配置成微调模式;

具体重启的原因,请大家参考Allen Gao写的博客 :如何诊断节点重启问题


这里介绍几个主流linux和unix平台上NTP微调的配置方法:


For Linux :


1.请确确认各节点的ntp包已经安装 ,我这里是个4.2.2的版本


[oracle@nascds10 ~]$ rpm -qa | grep ntp


ntp-4.2.2p1-9.el5_4.1


2.请编辑各个节点的ntp.conf文件


[oracle@nascds10 ~]$ su - root


Password:


[root@nascds10 ~]#  vi /etc/ntp.conf


#New ntp server added by Robinson


server  192.168.1.128 prefer  <<<<===========这里是时钟服务器


restrict 192.168.7.0  mask 255.255.255.255 nomodify notrap #基于网段的限制(限制在网段192.168.7.0)


broadcastdelay 0.008


[root@nascds11 ~]# vi /etc/ntp.conf


#New ntp server added by Robinson


server 192.168.7.71 prefer


broadcastdelay 0.008


3、配置ntpd的参数,我们主要强调的是要配置成"微调的模式" 也就是在options中要加入 -x的选项


[root@nascds10 ~]# vi /etc/sysconfig/ntpd


#The following item added by Robinson


#Set to 'yes' to sycn hw clock after successful ntpdate


SYNC_HWCLOCK=yes  


OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"


[root@nascds11 ~]# vi /etc/sysconfig/ntpd


The following item added by Robinson


SYNC_HWCLOCK=yes


OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"


4、自动启动配置


[root@nascds10 ~]# chkconfig ntpd on


[root@nascds11 ~]# chkconfig ntpd on


5、重启一下,使最新配置生效


[root@nascds10 ~]# service ntpd restart


Shutting down ntpd: [  OK  ]


ntpd: Synchronizing with time server: [  OK  ]


Syncing hardware clock to system time [  OK  ]


Starting ntpd: [  OK  ]


[root@nascds11 ~]# service ntpd restart


Shutting down ntpd: [  OK  ]


ntpd: Synchronizing with time server: [  OK  ]


Syncing hardware clock to system time [  OK  ]


Starting ntpd: [  OK  ]


6、检查ntpd进程的状态


[root@nascds10 ~]# ntpq -p


      remote           refid      st t when poll reach   delay   offset  jitter


==============================================================================


  LOCAL(0)        .LOCL.          10 l   40   64    1    0.000    0.000   0.001


[root@nascds11 ~]# ntpq -p


      remote           refid      st t when poll reach   delay   offset  jitter


==============================================================================


  test.oracle.com  .INIT.          16 u   60   64    0    0.000    0.000   0.000


  LOCAL(0)        .LOCL.          10 l   59   64    1    0.000    0.000   0.001




For Aix:




1. NTP的同步设置  编辑 /etc/ntp.conf文件, 内容如下:


----------------------------


#broadcastclient


server 192.168.5.2 


driftfile /etc/ntp.drift


tracefile /etc/ntp.trace


slewalways yes


----------------------------


我们这里还是要强调微调slewalways  ,这个值的默认设置是no,也就是说如果您不设置,NTP最大可一次调整1000秒. 根据IBM的官方说明,如果我们不指定slewthreshold  那么默认值是 0.128 seconds. 如果想特别设置,请指定slewthreshold 的值,注意单位是second




2.在NTP客户端启动xntpd守护进程


# startsrc -s xntpd



3. 查询xntpd的状态


当 system peer 不为 'insane' 时, 表明客户端已与服务器端成功地进行了同步.


# lssrc -ls xntpd


Program name: --/usr/sbin/xntpd


Version: -------3


Leap indicator: 00 (No leap second today.) Sys peer: ------192.168.5.2 ...




关于更多的关于IBM的平台上NTP的设置,可以参考IBM的官方文档解释:


http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/ntp.conf.htm



For HP  UX:



NTP在HP上的配置,是比较省心的,不容易导致RAC重启的,因为HP上的NTP默认的就是微调的模式


1、首先我们还是要编辑ntp的配置文件 /etc/rc.config.d/netdaemons,把 XNTPD 设定为1表示启动


   export XNTPD=1


2、编辑配置文件 /etc/ntp.conf ,配置好时间同步服务器


   server 192.168.5.2      #  第一个地址是主服务器


   server 192.168.5.3      #  第二个地址是备用服务器


3、启动ntp的进程


   # /sbin/init.d/xntpd start


4、检查NTP的状态


   # /usr/sbin/ntpq -p


  这个命令您会看到同步的地址


  如果出现的结果是No association ID's returned 那么表示您失败了


关于HP主机上NTP的模式,有3种如下,在HP 平台的man page中有详细的说明:


模式1:offset below 128 milliseconds

This is the normal operating regime of NTP. A properly configured NTP hierarchy (with reasonable networking) can operate for years without ever approaching the 128 millisecond upper limit. All time adjustments are small and smooth (known as slewing), and nobody even notices the slew adjustments unless they have a cesium clock or a GPS clock and expensive instrumentation to make sophisticated measurements (HP/Agilent makes the instruments).

模式2:offset above 128 milliseconds

This regime is often encountered at power-on because, those battery-backed real-time clocks they put in computers are not too great. Because NTP is quite capable of keeping the offset below one millisecond all the time it is running, many users want to get into the normal regime quickly when an offset above 128 millisecond is encountered at startup. So in this situation NTP will (fairly quickly) make a single step change, and is usually successful in getting the offset well below 128 millisecond so there will be no more of the disruptive step changes.


模式3:offset above 1000 seconds


This is so far out of the normal operating range that NTP decides something is terribly wrong and human intervention is required. The daemon shuts down.


For Solars:


我这没有测试的平台,不过在KM (How to Configure NTP or Windows Time for Oracle Clusterware (Doc ID 1056693.1))里找到了配置的办法,这里还有Windows的配置方式


检查配置:


/usr/bin/svcs ntp


STATE          STIME    FMRI


online          7:39:29 svc:/network/ntp:default


ps -ef|grep ntp


root 21212     1   0   Feb 02 ?           0:33 /usr/lib/inet/xntpd



配置/etc/inet/ntp.conf 启用slewalaways


grep 'slewalways|pll' /etc/inet/ntp.conf


slewalways yes


disable pll


启动:


/usr/sbin/svcadm enable ntp

星期日 九月 22, 2013

TimesTen学习资料大汇总

想学习TimesTen内存数据库,苦于相关资料太少?


好消息来了!



如果您的英文不够好,可以通过以下三种渠道来获得相关信息:




1. support.oracle.com 网站已经开始陆续推出TimesTen中文翻译文档。

以下是翻译好的部分文章列表:

TimesTen 内存数据库 (IMDB) 版本支持摘要 [ID 1536728.1]

如何评估发生TimesTen core dumps后的Core 文件的大小 [ID 1566407.1]

如何评估,计算和配置TimesTen 日志定期归档的问题 [ID 1566405.1]

TimesTen中,多久需要更新统计信息? [ID 1566430.1]




2. 到我们的数据库中文社区提问和浏览。




3. 关注我们的中文博客:






如果您的英文足够好,这里给出了一系列链接和文档号,供您学习:



-- 下载软件




-- 下载搭建自己的TimesTen 开发环境:




-- 研读在线文档:




-- 访问我们英文社区并关注我们定期举办的在线直播研讨会




-- 关注我们英文博客




-- 到论坛浏览或者提问




-- 更多文章,尽在support.oracle.com!



------

Master Note : TimesTen In-Memory Database (Doc ID 1088128.1)

Index Note : TimesTen Documentation For Webcasts (Doc ID 1263225.1)

“HOW TO”?

How To Gracefully shutdown a TimesTen system. (Doc ID 1326710.1)

HOWTO : Understand A General Overview Of How TimesTen Uses CPU (Doc ID 416395.1)

How to reload a TimesTen datastore? (Doc ID 789949.1)

How to verify which ports have been configured for TimesTen (Doc ID 462255.1)

How To Reduce PermSize Settings For An Existing TimesTen Data Store (Doc ID 1081032.1)

HOWTO Enable Date and Time Stamp in TimesTen Logs on Unix (Doc ID 755483.1)

Explaining how Server Connection Attributes work: MaxConnsPerServer, ServersPerDSN, and serverpool (Doc ID 1184993.1)

HOWTO : Understand TimesTen Client-Server Configuration Options (Doc ID 1273911.1)



Installation & Backup & Migration & Upgrading

-- Installation

http://docs.oracle.com/cd/E13085_01/doc/timesten.1121/e13063/install.htm#CBHDBEIG

-- Upgrading

http://docs.oracle.com/cd/E13085_01/doc/timesten.1121/e13063/upgrade.htm

-- Backup & Migration

How to migrate a data store from Solaris to Linux? (Doc ID 1302794.1)

Index Behaviour During Timesten Migration (Doc ID 1214634.1)

HOWTO : Understand Moving or Copying A TimesTen Database (Doc ID 974583.1)

TimesTen: Can I Do an Offline Backup? (Doc ID 747801.1)

HOWTO : Use ttMigrateCS To Migrating Across OS Or Chip Set Platforms (Doc ID 1299746.1)

HOWTO : Understand Converting To A Database Characterset From TimesTen A TIMESTEN8 Characterset (Doc ID 1257114.1)

--------------------

Troubleshooting & Monitoring

Index Note : TimesTen Best Practices For Monitoring (Doc ID 1313448.1)

Troubleshooting TimesTen In-Memory Database (Doc ID 406904.1)

How to troubleshoot process using high memory problems (Doc ID 1349825.1)

Troubleshooting TimesTen Replication (Versions 6 & 7) (Doc ID 406867.1)

Monitoring Memory Usage in Virtual Memory Systems (Doc ID 558237.1)

TimesTen Health Monitoring (Doc ID 789629.1)


--------------------------

Development & Maintence

How To Gracefully shutdown a TimesTen system.(Doc ID 1326710.1)

Externally Signaling A Graceful Shutdown in TimesTen Client Processes (Doc ID 884883.1)

Guidelines for Shutting Down TimesTen DataStores and Applications (Doc ID 740819.1)

HOWTO : Understanding Methods For Showing A Query Plan (Doc ID 953297.1)

TimesTen Case Study: "Connection Storm" Appears To Hang Entire Application (Doc ID 1477100.1)

HOWTO : Modify A View In A TimesTen Active Standby Pair (Doc ID 1311731.1) 

--------------------------

For Replication

TimesTen: How to configure Active/Standby pair setup with Oracle Clusterware (CRS)? (Doc ID 809197.1)

TimesTen - Replication Daemon Executable Size Can Grow To Be Very Large (Doc ID 1375872.1)

HOWTO Set-up and Tear-down A TimesTen Master and Subscriber Database Replication Scheme (Doc ID 752168.1)

HOWTO : Understand TimesTen: LSNs, Bookmarks and Replication (Doc ID 786982.1)

TimesTen: Details of the "TTRepAdmin -duplicate" operation (Doc ID 787019.1)

--------------------------

For Cache to Oracle

Quick Start Guide - Getting started with TimesTen Cache (Doc ID 549803.1)C

Steps to use Active Standby replication in a Cache Grid environment (Doc ID 844517.1)

Steps to add a TimesTen node into an existing Cache Grid (Doc ID 842990.1) )

What is the best practice for gracefully detaching a database from a TimesTen Cache Grid?

TimesTen Cache Connect to Oracle: Internals, Performance Hazards and Performance Tuning (Doc ID 473493.1)

HOW TO HANDLE SHUTDOWN/RESTART OF CACHE GRID AFTER A SERVER REBOOT (Doc ID 973717.1)

------

AIX Specific

Note:1354237.1 - Timesten Datastore loads Very Slowly on IBM AIX systems (Doc ID 1354237.1)

Note:1311244.1 - Why do I see multiple shared memory segments used for a TimesTen datastore on AIX?

Note:867692.1 - Using the AIX "Large Pages" Facility to Pin TimesTen Segments in Memory

------


如果您觉得有其他更好的渠道和资料,也欢迎您分享到这里!


















星期三 九月 18, 2013

TimesTen的Active-standby配置中如何安全重启Active节点主机

TimesTen的Active-Standby pair是TimesTen中的HA配置,但是和Oracle的Physical/Logical Standby又有区别。其同步方法和Logical Standby类似,是应用Active主机的transaction log.

但是Standby主机是只读的。

重启Standby主机没有问题,日志会堆积在Active端,等standby重启后会自动接续。

但是很多客户发现重启Active主机,经常会导致Active-Standby pair丢失。即使用户先将Standby转换成Active,再重启原来的Active主机(转换后的standby)也不行。

这将总是需要重建原来的Active主机(转换后的standby)上的数据库,在数据量巨大时,这个过程将非常缓慢。


经过反复实验和考证,我们现在可以确认问题出在哪里:

1)Active主机在重启前,并未将所有的transaction都同步到Standby,如果一旦Active和Standby角色互换,会造成Standby上存在Active上并不存在的transaction,产生TT16227错误:

TT16227: Standby store has replicated transactions not present on the active. Local CTN=1377070661.7568, Backup CTN=1376558513.698865, Received CTN=1377070661.7564.

2)用户只是用了./ttdaemonadmin -stopserver -force来尝试中止所有应用连接。

需要指出的是TimesTen有两种连接,一种是C/S,一种是直连。



C/S是指应用程序和TimesTen不在同一台主机上的连接方式。对于同一台主机上的程序,可以使用直连。

而./ttdaemonadmin -stopserver只会停止C/S连接。

同一台主机上,仍可以通过ttisql登录数据库。

3)如果停止所有应用,并确认Active-standby两侧的transaction同步后,可以做任意重启操作。如果要使用force或者杀进程停止transaction的话,一定要确认回滚完毕并且两侧确认同步后,再重启。可以用dsmap工具来实现确认动作。


下面给出了详细的重启Active主机的确认步骤:



1)停止Server来中断已有的并阻止未来的client/Server连接.

./ttdaemonadmin -stopserver -force


2)杀用户进程,主要是杀Direct link连接:

Command> host ttXactAdmin -connections

2013-08-26 14:32:44.696

/home/oracle/TimesTen/tt1121/info/HHCBEDATA

TimesTen Release 11.2.1.9.8


ID   PID     Context    Name           Program        State TransID     UID


1 32654   0x082723b8 hhcbedata      ttIsqlCmd      Run      1.88     TTADMIN <==========ttIsqlCmd连接需要kill

2 32663   0x0a1ff1b0 REPHOLD        timestenrepd   Run               SYS

3 32663   0x0a24fda0 FAILOVER       timestenrepd   Run               SYS

4 32663   0x92c00468 REPLISTENER    timestenrepd   Run               SYS

5 32663   0x0a2a0990 XLA_PARENT     timestenrepd   Run               SYS

6 32663   0x0a17ca18 LOGFORCE       timestenrepd   Run               SYS

7 32663   0x0a3117e8 TRANSMITTER    timestenrepd   Run               SYS

8 32663   0x0a3623d8 RECEIVER       timestenrepd   Run               SYS

9 437     0x09cfaba0 hhcbedata      ttIsqlCmd      Run               ORACLE <=========这是你的当前连接

2032 32564   0x0830e340 Manager        timestensubd   Run               SYS

2033 32564   0x08360e98 Rollback       timestensubd   Run               SYS

2034 32564   0x0842f538 Flusher        timestensubd   Run               SYS

2035 32564   0x084a05a0 Monitor        timestensubd   Run               SYS

2036 32564   0x084f13a0 Deadlock Detector timestensubd   Run               SYS

2037 32564   0x085421a0 Checkpoint     timestensubd   Run               SYS

2038 32564   0x08592fa0 Aging          timestensubd   Run               SYS

2039 32564   0x085e3da0 Log Marker     timestensubd   Run               SYS

2040 32564   0x08634ba0 AsyncMV        timestensubd   Run               SYS

2041 32564   0x086859a0 HistGC         timestensubd   Run               SYS


3)等待并确认Active-standby两侧的transaction同步:


Command> call ttRepSubscriberWait(null, null, null, null, -1);


TIMEOUT:   00

Command> vertical 1;

Command> select * from ttrep.reppeers;


COMMIT_TIMESTAMP:    1377498342

COMMIT_SEQNUM:       352                   <==============352


-bash-3.2$ cd ../support

-bash-3.2$ ./dsmap -shmid 4161544 -hdr| grep -i ctn  <===========4161544 是通过ttstatus命令获得的shared memory ID

 latch                   = 9     (SbCTNWrapLatch)

 latch                   = 10    (SbRepCTNLatch)

replBackupCTN             = <0.0>

locCTN                    = <1377498342.352>

appliedCTN                = <1377498342.352> <==============352

lastLocalAwtCTN           = <0.0>

lastGlobalAwtCTN          = <0.0>


<======需要等到COMMIT_TIMESTAMP.COMMIT_SEQNUM=dsmap命令结果中的locCTN,并且等于appliedCTN


4)在standby上执行角色转换,(如果应用不需要在这段时间内切换到Standby上,也可以不执行):


call ttrepstateset('ACTIVE');

call ttrepstateget;


5)在以前的Active上执行以下命令然后:

./ttAdmin -repStop HHCBEDATA

./ttadmin -ramunload  "dsn=HHCBEDATA"

./ttDaemonAdmin -stop


<====现在可以安全重启Active主机了

星期二 九月 17, 2013

如何配置SQL developer从windows客户端远程连接TimesTen


配置SQL developerwindows客户端远程连接TimesTen之前,Windows上必须要安装TimesTen Client软件才会有远程连接必要的客户端程序及TimesTen for windows ODBC 驱动。


1)在以下连接下载最新的TimesTen for windows,需要说明的是,TimesTen的服务器和客户端是下载同一个安装程序,如果只安装客户端,可以安装时自定义安装选择只装客户端。


http://www.oracle.com/technetwork/products/timesten/downloads/index.html



需要先点击“Accept License Agreement才能下载。


2)Windows7上安装,以管理员身份运行setup.exe



3)选择只安装TimesTen Client:



4)安装步骤的最后一步,让安装程序自动注册TimesTen的环境变量。



5)ODBC中添加一个数据源,选择TimesTen Client:


(64位系统上打开32ODBC管理器需要在cmd运行%systemdrive%\Windows\SysWoW64\Odbcad32.exe)




6)点击Servers按钮,配置TimesTen服务器端口。


7)在这个界面点Add添加一个服务器:



8)服务器地址及端口号:



端口号可以通过在服务器上执行ttstatus获得:


-bash-3.2$ ttstatus


TimesTen status report as of Tue Aug 27 10:51:21 2013


Daemon pid 650 port 53380 instance tt1121


TimesTen server pid 14608 started on port 53381 ç=========53381端口


9)选择服务器,填写DSN,用户名密码可填写,不填写的话会要求在连接时再输入。



10)重新启动sql developer,因为安装客户端时注册了环境变量,再次启动sql developer会发现新建数据库连接页出现了TimesTen选项:



11)选择刚才添加的ODBC数据源即可。



点击“连接”就可以连接上TimesTen数据库了。


12)如果不使用ODBC的自定义配置:


以上使用ODBC是最简洁明了的配置,但是很多用户还是想直接写连接字符串,这里也给出方法。从第5步开始省略,安装完客户端后在sql developer中直接输入连接字符串:


TTC_Server=hostname;TTC_Server_DSN=Server_DSN;TCP_Port=Server_port


这里


o Hostname: TimesTen的主机名或者IP地址


o TTC_SERVER_DSN: TimesTen DSN 名,也就是Datastore的名称。


o Server_port: 我们之前用ttstatus看到的���务端口号。


TimesTen server pid 14608 started on port 53381 ç=========53381端口


例如可以设置为:


TTC_Server=nascds8;TTC_Server_DSN=HHCBEDATA;TCP_Port=53381


注意要填写用户名口令:



星期五 七月 12, 2013

CSS 功能简介


最近处理了一些和CSS(Cluster
Synchronization Service)
相关的问题,进而对CSS 的功能有了一些粗浅的认识,尤其是GM(Group Management)部分的功能,在这里和大家分享一下,希望对我们今后处理CSS 问题和理解CSS 这个oracle
集群的核心组件有所帮助。


CSS的功能主要包括节点管理(Node Management,以下简称NM)和组管理(Group Management,以下简称GM)两部分,都是由守护进程ocssd.bin 来实现的,这是个多线程的进程(我们可以通过命令pstack获得更多线程的信息,本文并不会详细的介绍每个线程的功能)。


首先,NM主要负责集群中节点的管理。集群是由若干个节点构成的,NM要解决的问题就是如何让集群的各个节点处于一致的状态,以及,当集群成员发生改变时,如果维护集群的一致性。所以,NM要实现下列的功能:


1. 节点间的网络心跳:通过集群私网,每一个节点都定期向其他所有的节点发送网络心跳,以便确认节点之间的通信和健康性。


2. 磁盘心跳:只有网络心跳是不够的,因为,一旦出现了网络问题,当节点间互相无法发现对方的网络心跳时,无法判断那一个(些)节点的状态正常,哪一些不正常,所以,我们还需要磁盘心跳。每个节点会定期向表决盘(VF)中注册本地节点的状态信息。这样,当网络心跳出现问题时,我们就可以基于表决盘中的信息,判断节点的状态并作出正确的决定,并防止脑裂(split brain)的发生。


3. 集群节点重新配置:ocssd.bin会每隔一段时间都对集群中的每个节点的最后一次网络心跳和磁盘心跳进行判断,以决定是否需要对集群进行重新配置(也就是说,是否有某一个/些节点需要被evict掉)。当然,当一个节点加入集群时,集群的其他节点需要收到集群重新配置的信息,得到最新的节点成员列表。同样的道理,当集群的某一个节点离开集群时,其他节点需要知道最新的成员列表。当然,无论是节点加入或者离开集群,都会有一个RMN(reconfig)节点负责集群的重新配置,并���知集群中的其他节点。


注意:以上内容是针对cssd.bin的基本功能进行的介绍,对已11gR2的新特性,如:本地心跳,cssdagent/cssdmonitor, rebootless restart,在本文并不包括。如果您对这些新特性感兴趣,请参考之前的文章。


 接下来,我们介绍一下GM这部分的功能。在一个集群中,除了节点之外,还有很多资源是需要管理的,(当然,主要的资源管理工作是由crsd.bin来完成的)而这些资源会作为一个一个的组(在css的世界里,我们把组称为grock)注册到css上,每一个组会由若干个成员构成,而且每一个组或者组中的一些成员都要向外共享一些信息。例如,集群中的每一个数据库都会作为一个组注册到css上,而这个组的主要的成员就是lmon进程(这就是为什么,有的时候我们会发现lmon进程有的时候会报ora-29701错误的原因。),当一个进程被启动的时候,本地实例的lmon进程需要把自己注册到css对应的组当中,它才能够知道,这个数据库同时又多少个实例在运行,每个实例运行在哪一个节点,对于这种行为,我们一般称之为组内共享。
再举一个例子,当ASM实例启动之后,ASM对应的组会把自己的信息共享出去,以便数据库实例能够发现运行的ASM实例,并进行通信,对于这种行为,我们一般称之为组间共享。如果一个组的所有成员都来自于同一个节点,我们称之为本地组;如果组中的成员来自不同的节点,我们称之为全局组。


NM类似,当组中的某一个成员离开或者加入组的时候,也会有一个master节点(一般称这个节点为GM master)来完成组成员的重新配置。另外,组管理中另一个重要的功能就是fencing,也就是说,当组中的某一个成员离开的时候(例如:这个进程被terminate掉),css 必须确保这个进程在OS 级别已经离开,而且进程pending的所有I/O 操作都被清理掉,因为对于集群来说,我们需要在节点间保证I/O的一致性,这也是我们经常在很多文档当中会讲到,只有I/O capability的进程才会注册到css的原因之一。


最后,由于CSS的首要功能是构建集群和确保集群的一致性,所以,当集群的节点数量发生改变的时候(节点加入集群,或者离开集群),css 首先会进行NM层面的重新配置,之后才能进行GM层面的重新配置,这个顺序是不能颠倒,也不能同时进行的。这也从某种程度上解释了,为什么我们会看到,当ocssd.bin 没有完成工作的时候,crsd.bin是不能启动所管理的资源的。


以上的内容希望对大家理解CSS这个oracle集群核心进程的功能有些帮助。在今后的文章中我们会尝试通过一些具体的例子来对上面的内容进行解释。


参与此主题的后续讨论,可以访问我们的中文社区,跟帖“共享: CSS 功能简介"

星期一 五月 27, 2013

关于正则表达式

Oracle在10G之前的版本,对于字符串的处理有很大的局限性。ORACLE 10G引入的正则表达式的函数 ,对字符串的处理有了极大的提
高。接下来会给大家介绍相关函数的语法,以及通过一些简单的例子来说明正则表达式的应用。



请在此链接下载全文:  关于正则表达式


参与此主题的后续讨论,可以访问我们的中文社区,跟帖分享 : 关于正则表达式

星期四 五月 23, 2013

在AIX上运行RAC时网络方面的一些最佳经验

在AIX上运行RAC时网络方面的一些最佳经验

1. Oracle推荐使用Etherchannel来配置网卡绑定,推荐主/备模式的网卡绑定,主/主(Active/Active)模式不推荐,因为主/备模式更稳定一些。注意:从11.2.0.2开始,Oracle 的集群软件Grid Infrastructure(GI)中新增了Redundant Interconnect with Highly Available IP(HAIP),以实现集群私网的高可用性和负载均衡。也就是说,有了HAIP之后,无需使用网卡绑定就可以实现私网网卡的冗余( 关于HAIP的更多信息,请参考 Redundant Interconnect with Highly Available IP (HAIP) 简介)。

2. Oracle针对网络的另外一个推荐是使用Jumbo Frames,网卡和交换机支持9000 MTU 大小就可以启用。MTU (Maximum Transmission Unit)是指最大的网络传输单位,默认一般是1500 bytes。由于在RAC实例间传输的数据可能在2K to 64K或者更大,当MTU是1500时,会导致这些数据被分割,对性能产生影响。启动Jumbo Frames后,MTU可以达到9000 bytes,这样可以降低数据被分割的次数。 更多信息,请参考MOS文档:
Recommendation for the Real Application Cluster Interconnect and Jumbo Frames (Note 341788.1)

3. 如果网络的一些参数设置不合理,可能会产生"gc cr multi block request" 这样的等待事件。如果在AWR中发现了这个等待事件很高,需要检查UDP 参数udp_sendspace和udp_recvspace的设置是否满足下面的要求:

针对AIX:
o 设置udp_sendspace >=[(DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4096],但是不低于 65536.
o 设置udp_recvspace 为 4到10倍的udp_sendpace
o 由于sb_max 必须 >= udp_recvspaceIf ,可能需要增加sb_max的值(默认为1048576)
o 如果udp的参数设置不合理,可能会产生“socket buffer overflows”,如果这个值非0, 需要增加udp_recvspace:
 netstat -s | grep "socket buffer overflows"

4. 针对交换机使用哪种协议,CRS 和 RAC 没有要求,如果使用了Etherchannel,只要这种协议和Etherchannel兼容并且稳定就可以。

下面的文档中有针对网络方面的一些要求:
Minimum Software Versions and Patches Required to Support Oracle Products on IBM Power Systems (Note 282036.1)
10 Gigabit Ethernet
. LACP timeout: Use the “long timeout” switch setting for the amount of time to wait
before sending LACPDUs.
· Flow control: Enable flow control at the switch port and on the server side ports
(using HMC) for the 10GE adapter or 10GE HEA configuration.

星期三 五月 08, 2013

RAC 中锁的管理—Buffer Lock

本文是前一篇文章《RAC 中锁(排队)的管理》的继续,在这篇文章中,我们会介绍RAC

中buffer lock(也称为PCM lock)是如何工作的。


首先,在数据库中,当我们需要访问一个buffer的时候,我们需要在对应的buffer上面加一个锁,而当一个进程持有这个buffer的lock时,其他的进程如果以不兼容的方式访问相同的buffer,就需要等待,对应的等待事件是’buffer busy wait’(不同的版本等待事件可能不同)。在RAC 数据库中,事情变得更加复杂了,由于所有实例访问相同的数据文件,我们需要在多个实例之间保证数据的一致性,所以, 在RAC 环境下buffer lock的结构更加的复杂。


RAC下的buffer lock 由3部分构成:

锁模式(lock mode):对于buffer lock,只有三种 N(空), S(共享)和X(独占)模式。下面的表格说明了各种模式的兼容性。  



锁角色(lock role):本地或共享。本地表示对应的块只在本地被修改过,全局表示对应的块在一个或多个远程缓存中被修改过。

旧镜象(past image):这部分的值为1 或 0。1 表示对应的块存在PI(past image), 0表示不存在。 PI的存在主要是加快RAC 介质恢复,在今后的文章我们会详细的介绍PI的功能。


另外,和RAC中的排队(enqueue)类似,每一个buffer lock都有一个主(master)节点,每个块的主节点是通过hash算法决定的(具体的算法在本文中不作讨论)。主节点包含了对应lock 的全局信息,而每个访问过对应块的节点都包含了本实例的锁信息。


接下来,我们通过下面的的例子说明在RAC 数据库中访问某个block时会发生什么事情。

1. 节点C要求读取块1008。



1)1008块的主节点被hash到D节点,之后节点C向主节点发送请求,要求以S模式锁定块1008。这时buffer lock的模式是SL0(S?hared ,L?local, 0?没有PI)。

2)主节点把对应的锁赋予节点C。

3)节点C 从数据文件中读取块108。

4)读取完成,节点C 以 获得对应的锁,属性为SL0。


2.节点B要求读取块1008。



1) 节点B向主节点D发出请求,要求以S模式锁定块1008。

2) 主节点D发现节点C已经以S模式获得了对应的锁,而且S锁之间是可兼容的,所以,不需要锁的转换,主节点D要求实例C发送块1008 给实例B。

3) 节点C发送对应的块给节点B。

4) 节点B通知主节点D,已经获得了块1008上的S 锁,属性为SL0。


3.节点B要求修改块1008 中的信息。



1) 节点B向主节点D发出请求,要求以X模式锁定块1008。

2) 主节点D发现节点C已经以S模式获得了对应的锁,而且S锁于X锁之间是不兼容的,所以,需要锁的转换,主节点D要求节点C将对应的锁级别降低为N,所得属性为NL0

3) 节点B将自己的所降级,并且将本地的块1008 标识为CR。之后,节点B将块1008 修改为块1009,同时将通知主节点锁的属性为XL0。

4.节点A要求修改块1009。


 1) 节点A向主节点D发出请求,要求以X模式锁定块1009。

2) 节点D发现节点B已经以X模式持有了对应的锁,而且X模式的锁是不能兼容的,所以,主节点D 要求节点B降级锁到N模式,同时由于块在节点A和B都被修改,所以,锁的角色变为全局(Global),而且节点B上的块会变成一个PI。也就是说这时,节点B上的锁的属性为NG1(模式—> N, 角色—>G, 存在PI—>1)。

3) 节点B完成锁的降级之后,把块1009传递给节点A。

4) 节点A修改块1009 为1013,同时将自己节点的锁设置为XG0,并且通知主节点。


5. 节点C 查询块1013。



1) 节点C发送请求给主节点D,要求以S模式锁定块1013.

2) 主节点发现节点A拥有最新的块1013,而且这个节点以X模式锁定了这个块,因为X和S锁是不兼容的,主节点发送请求给节点A,要求降级锁。

3) 节点A降级锁为S模式,同时,由于最新的块会发送给节点C,所以在节点A上的块1013变为PI。接下来,节点A把块1013发送给节点C。这是节点A上的锁为SG1。

4) 节点C收到最新的块1013,并且以S模式锁定块,并把自己的锁更新为SG0。最后,通知主节点D。


根据以上的说明,我们能够看到,对于RAC系统,当一个进程需要访问一个块时,一定要首先获得块上对应的锁,之后才能对块进行相应的操作。而且,在RAC系统中,无论数据库包含多少个节点,当访问一个buffer时,最多会有3个节点参与其中,他们是主节点,持有者节点和申请者节点。而且,每一次访问的时候,都要有消息在节点间不断的传递。另外,我们能看到,如果锁的角色是全局,那么我们要做的事情更多,也意味着我们要访问的代码深度也越多。这也从一个角度解释了为什么oracle 会在RAC中推出DRM,read mostly,reader bypass等新特性(关于后两个新特性,我们会在今后的文章介绍)。



最后,对于PCM lock,以上过程都是由 lms进程完成的。而对于enqueue,是由lmdj进程完成的。


以上的描述,希望对大家理解RAC数据库中锁的管理的机制有所帮助。在接下来的文章中,我们会通过详细的例子对以上的内容进行讲解。


参与此主题的后续讨论,可以访问我们的中文社区,跟帖“共享:RAC 中锁的管理—Buffer Lock��。

星期五 二月 22, 2013

DRM 简介

首先,我们对和DRM 相关的一些概念进行介绍。

Buffer: 对于RAC 数据库,当一个数据块被读入到buffer cache后,我们就称其为buffer , cache fusion 会将这个buffer作为resource来管理。


Master:在RAC 数据库的世界里,每一个resource都会有一个master实例,这个master实例会在shared pool 中(例如:gcs resource 和ges resource 部分)分配一些空间来存放和这个资源相关的信息,例如:哪一个实例拥有了这个buffer的最新版本,哪一个实例拥有了这个buffer的什么级别的lock等等。并且,负责维护和这个资源的状态。


接下来,我们对RAC 环境中,访问一个buffer的过程进行简单的描述。我们以一个4节点的RAC 数据库为例。注意,我们只会列出比较典型的一种情况,不会把所有可能的情况都一一列出,而且只是把步骤进行了简单的介绍。



步骤1:实例3需要以X(exclusive)方式访问buffer1, 向master实例(1) 发出了请求。

步骤2:master实例(1)发现实例2 以X方式持有buffer1,之后通知实例2释放X lock,并把buffer1发送给实例3。

步骤3: 实例2释放X lock,并把最新版本的buffer1发送给实例3。

步骤4:实例3获得buffer1, 并通知master 实例(1)更新资源buffer1的最新状态。


从上面的步骤,我们不难看出,在RAC 数据库中,当我们访问一个buffer的时候,最多会有3个实例参与其中,master实例,holder(持有者)实例 和requestor(申请者) 实例。2种数据传输会出现,message:用于和lock相关的信息传输,data:用于传输buffer。同时,根据上面的步骤我们也自然会想到,如果master和requestor在同一个实例上,那么就可以减少实例之间message的传输并且访问的代码路径(code path)会更短,从而提高性能,但是每个buffer在被读取到buffer cache时,master节点的选择是随机的。基于这种考虑, oracle从10g开始,推出了一个新特性DRM(Dynamic Resource management)。



DRM的主要功能是,根据一段时间内(默认10分钟),每个实例,对某一个数据库对象的 (10gR1以数据文件为单位)的访问次数和方式,来决定数据库对象对应的buffer应该被mastering 到哪一个实例。在指定时间内,如果某一个实例访问某个数据库对象次数高于其他实例一定倍数(默认50倍),则oracle 会把这个对象所有的buffer的master信息,转移到对应实例(注意:不是转移buffer)。当然,转移的过程是渐进式的。当oracle 决定将一个buffer的master实例确定到本地实例后,会对这个buffer上加上affinity lock,来实现快速的访问。这也是我们经常提到的object affinity 的由来。


接下来,我们对DRM的基本步骤进行介绍。

1. Oracle停止所有在需要进行remastering的buffer上的操作。注意:DRM是渐进的,也就是说以windows 为单位,每次对一部分的buffer 进行remastering 操作。

2. Lmon 通知所有实例,准备进行remastering

3. 在旧的master实例清除对应buffer的master信息

4. 将master信息传递给新的master实例

5. 在新的master实例构建资源的最新状态

6. 结束,并释放所有之前所有步骤占用的资源。


然后,我们对DRM相关的一些参数进行简单的介绍。

_gc_policy_time :单位为分钟,控制DRM统计实例访问buffer次数的时间间隔,默认为是10分钟。

_gc_affinity_ratio:控制进行remastering所需要达到的最小比例(阀值),默认为50。也就是说,如果某个实例在10分钟(_gc_policy_time)之内,访问某个数据库对象的次数大于其他所有实例50倍时(注意:是50倍,而不是50次),对该数据库对象的buffer进行remastering。


注意:请不要修改以上参数的值,除非您很清楚自己在做什么,或者是根据oracle 工程师的建议。


最后,如果您遇到了和DRM相关的问题,建议您查看以下的信息。

1. Lmon,lmd,lms和diag进程的 trace file,来确认问题出现在DRM的哪一步和lms,lmon,lmd进程的状态。

2. AWR 和ASH report,确认那些等待事件持续了很长时间,以及lmon,lms 和lmd的状态。

3. 参照note 1492990.1 获取 DMR 诊断脚本输出。


希望以上的介绍对理解DRM有些帮助。

About

本博客由Oracle全球技术支持中国区的工程师维护。为中文用户提供数据库相关的技术支持信息,包括常用的诊断工具、诊断方法、产品新特性、案例分析等。此外,MOS也陆续推出各类中文内容:技术通讯统一发布在Note 1529795.1 中,中文文档列表更新在Note 1533057.1 中,网上讲座请查看MOS文档 1456176.1,在"Archived"中可以下载历史的录音和文档。

Search

Archives
« 五月 2015
星期日星期一星期二星期三星期四星期五星期六
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
22
23
24
25
26
27
28
29
30
31
      
今天