星期四 四月 16, 2015

如何通过dba_hist_active_sess_history分析历史数据库性能问题

如何通过dba_hist_active_sess_history分析历史数据库性能问题

背景
在很多情况下,当数据库发生性能问题的时候,我们并没有机会来收集足够的诊断信息,比如system state dump或者hang analyze,甚至问题发生的时候DBA根本不在场。这给我们诊断问题带来很大的困难。那么在这种情况下,我们是否能在事后收集一些信息来分析问题的原因呢?在Oracle 10G或者更高版本上,答案是肯定的。本文我们将介绍一种通过dba_hist_active_sess_history的数据来分析问题的一种方法。

适用于
Oracle 10G或更高版本,本文适用于任何平台。

详情
在Oracle 10G中,我们引入了AWR和ASH采样机制,有一个视图gv$active_session_history会每秒钟将数据库所有节点的Active Session采样一次,而dba_hist_active_sess_history则会将gv$active_session_history里的数据每10秒采样一次并持久化保存。基于这个特征,我们可以通过分析dba_hist_active_sess_history的Session采样情况,来定位问题发生的准确时间范围,并且可以观察每个采样点的top event和top holder。下面通过一个例子来详细说明。

1. Dump出问题期间的ASH数据:
为了不影响生产系统,我们可以将问题大概期间的ASH数据export出来在测试机上分析。
基于dba_hist_active_sess_history创建一个新表m_ash,然后将其通过exp/imp导入到测试机。在发生问题的数据库上执行exp:
SQL> conn user/passwd
SQL> create table m_ash as select * from dba_hist_active_sess_history where SAMPLE_TIME between TO_TIMESTAMP ('<time_begin>', 'YYYY-MM-DD HH24:MI:SS') and TO_TIMESTAMP ('<time_end>', 'YYYY-MM-DD HH24:MI:SS');

$ exp user/passwd file=m_ash.dmp tables=(m_ash) log=m_ash.exp.log

然后导入到测试机:
$ imp user/passwd file=m_ash.dmp log=m_ash.imp.log

2. 验证导出的ASH时间范围:
为了加快速度,我们采用了并行查询。另外建议采用Oracle SQL Developer来查询以防止输出结果折行不便于观察。

set line 200 pages 1000
col sample_time for a25
col event for a40
alter session set nls_timestamp_format='yyyy-mm-dd hh24:mi:ss.ff';

select /*+ parallel 8 */
 t.dbid, t.instance_number, min(sample_time), max(sample_time), count(*) session_count
  from m_ash t
 group by t.dbid, t.instance_number
 order by dbid, instance_number;

INSTANCE_NUMBER    MIN(SAMPLE_TIME)    MAX(SAMPLE_TIME)    SESSION_COUNT
1    2015-03-26 21:00:04.278    2015-03-26 22:59:48.387    2171
2    2015-03-26 21:02:12.047    2015-03-26 22:59:42.584    36

从以上输出可知该数据库共2个节点,采样时间共2小时,节点1的采样比节点2要多很多,问题可能发生在节点1上。

3. 确认问题发生的精确时间范围:
参考如下脚本:

select /*+ parallel 8 */
 dbid, instance_number, sample_id, sample_time, count(*) session_count
  from m_ash t
 group by dbid, instance_number, sample_id, sample_time
 order by dbid, instance_number, sample_time;

INSTANCE_NUMBER    SAMPLE_ID    SAMPLE_TIME    SESSION_COUNT
1    36402900    2015-03-26 22:02:50.985    4
1    36402910    2015-03-26 22:03:01.095    1
1    36402920    2015-03-26 22:03:11.195    1
1    36402930    2015-03-26 22:03:21.966    21
1    36402940    2015-03-26 22:03:32.116    102
1    36402950    2015-03-26 22:03:42.226    181
1    36402960    2015-03-26 22:03:52.326    200
1    36402970    2015-03-26 22:04:02.446    227
1    36402980    2015-03-26 22:04:12.566    242
1    36402990    2015-03-26 22:04:22.666    259
1    36403000    2015-03-26 22:04:32.846    289
1    36403010    2015-03-26 22:04:42.966    147
1    36403020    2015-03-26 22:04:53.076    2
1    36403030    2015-03-26 22:05:03.186    4
1    36403040    2015-03-26 22:05:13.296    1
1    36403050    2015-03-26 22:05:23.398    1

注意观察以上输出的每个采样点的active session的数量,数量突然变多往往意味着问题发生了。从以上输出可以确定问题发生的精确时间在2015-03-26 22:03:21 ~ 22:04:42,问题持续了大约1.5分钟。
注意: 观察以上的输出有无断档,比如某些时间没有采样。

4. 确定每个采样点的top n event:
在这里我们指定的是top 2 event,并且注掉了采样时间以观察所有采样点的情况。如果数据量较多,您也可以通过开启sample_time的注释来观察某个时间段的情况。注意最后一列session_count指的是该采样点上的等待该event的session数量。

select t.dbid,
       t.sample_id,
       t.sample_time,
       t.instance_number,
       t.event,
       t.session_state,
       t.c session_count
  from (select t.*,
               rank() over(partition by dbid, instance_number, sample_time order by c desc) r
          from (select /*+ parallel 8 */
                 t.*,
                 count(*) over(partition by dbid, instance_number, sample_time, event) c,
                 row_number() over(partition by dbid, instance_number, sample_time, event order by 1) r1
                  from m_ash t
                /*where sample_time >
                    to_timestamp('2013-11-17 13:59:00',
                                 'yyyy-mm-dd hh24:mi:ss')
                and sample_time <
                    to_timestamp('2013-11-17 14:10:00',
                                 'yyyy-mm-dd hh24:mi:ss')*/
                ) t
         where r1 = 1) t
 where r < 3
 order by dbid, instance_number, sample_time, r;

SAMPLE_ID    SAMPLE_TIME    INSTANCE_NUMBER    EVENT    SESSION_STATE    SESSION_COUNT
36402900    22:02:50.985    1        ON CPU    3
36402900    22:02:50.985    1    db file sequential read    WAITING    1
36402910    22:03:01.095    1        ON CPU    1
36402920    22:03:11.195    1    db file parallel read    WAITING    1
36402930    22:03:21.966    1    cursor: pin S wait on X    WAITING    11
36402930    22:03:21.966    1    latch: shared pool    WAITING    4
36402940    22:03:32.116    1    cursor: pin S wait on X    WAITING    83
36402940    22:03:32.116    1    SGA: allocation forcing component growth    WAITING    16
36402950    22:03:42.226    1    cursor: pin S wait on X    WAITING    161
36402950    22:03:42.226    1    SGA: allocation forcing component growth    WAITING    17
36402960    22:03:52.326    1    cursor: pin S wait on X    WAITING    177
36402960    22:03:52.326    1    SGA: allocation forcing component growth    WAITING    20
36402970    22:04:02.446    1    cursor: pin S wait on X    WAITING    204
36402970    22:04:02.446    1    SGA: allocation forcing component growth    WAITING    20
36402980    22:04:12.566    1    cursor: pin S wait on X    WAITING    219
36402980    22:04:12.566    1    SGA: allocation forcing component growth    WAITING    20
36402990    22:04:22.666    1    cursor: pin S wait on X    WAITING    236
36402990    22:04:22.666    1    SGA: allocation forcing component growth    WAITING    20
36403000    22:04:32.846    1    cursor: pin S wait on X    WAITING    265
36403000    22:04:32.846    1    SGA: allocation forcing component growth    WAITING    20
36403010    22:04:42.966    1    enq: US - contention    WAITING    69
36403010    22:04:42.966    1    latch: row cache objects    WAITING    56
36403020    22:04:53.076    1    db file scattered read    WAITING    1
36403020    22:04:53.076    1    db file sequential read    WAITING    1

从以上输出我们可以发现问题期间最严重的等待为cursor: pin S wait on X,高峰期等待该event的session数达到了265个,其次为SGA: allocation forcing component growth,高峰期session为20个。

注意:
1) 再次确认以上输出有无断档,是否有某些时间没有采样。
2) 注意那些session_state为ON CPU的输出,比较ON CPU的进程个数与您的OS物理CPU的个数,如果接近或者超过物理CPU个数,那么您还需要检查OS当时的CPU资源状况,比如OSWatcher/NMON等工具,高的CPU Run Queue可能引发该问题,当然也可能是问题的结果,需要结合OSWatcher和ASH的时间顺序来验证。

5. 观察每个采样点的等待链:
其原理为通过dba_hist_active_sess_history. blocking_session记录的holder来通过connect by级联查询,找出最终的holder. 在RAC环境中,每个节点的ASH采样的时间很多情况下并不是一致的,因此您可以通过将本SQL的第二段注释的sample_time稍作修改让不同节点相差1秒的采样时间可以比较(注意最好也将partition by中的sample_time做相应修改)。该输出中isleaf=1的都是最终holder,而iscycle=1的代表死锁了(也就是在同一个采样点中a等b,b等c,而c又等a,这种情况如果持续发生,那么尤其值得关注)。采用如下查询能观察到阻塞链。

select /*+ parallel 8 */
 level                     lv,
 connect_by_isleaf         isleaf,
 connect_by_iscycle        iscycle,
 t.dbid,
 t.sample_id,
 t.sample_time,
 t.instance_number,
 t.session_id,
 t.sql_id,
 t.session_type,
 t.event,
 t.session_state,
 t.blocking_inst_id,
 t.blocking_session,
 t.blocking_session_status
  from m_ash t
/*where sample_time >
    to_timestamp('2013-11-17 13:55:00',
                 'yyyy-mm-dd hh24:mi:ss')
and sample_time <
    to_timestamp('2013-11-17 14:10:00',
                 'yyyy-mm-dd hh24:mi:ss')*/
 start with blocking_session is not null
connect by nocycle
 prior dbid = dbid
       and prior sample_time = sample_time
          /*and ((prior sample_time) - sample_time between interval '-1'
          second and interval '1' second)*/
       and prior blocking_inst_id = instance_number
       and prior blocking_session = session_id
       and prior blocking_session_serial# = session_serial#;

LV    ISLEAF    ISCYCLE    SAMPLE_TIME    INSTANCE_NUMBER    SESSION_ID    SQL_ID    EVENT    SESSION_STATE    BLOCKING_INST_ID    BLOCKING_SESSION    BLOCKING_SESSION_STATUS
1    0    0    22:04:32.846    1    1259    3ajt2htrmb83y    cursor:    WAITING    1    537    VALID
2    1    0    22:04:32.846    1    537    3ajt2htrmb83y    SGA:    WAITING            UNKNOWN

注意为了输出便于阅读,我们将等待event做了简写,下同。从上面的输出可见,在相同的采样点上(22:04:32.846),节点1 session 1259在等待cursor: pin S wait on X,其被节点1 session 537阻塞,而节点1 session 537又在等待SGA: allocation forcing component growth,并且ASH没有采集到其holder,因此这里cursor: pin S wait on X只是一个表面现象,问题的原因在于SGA: allocation forcing component growth

6. 基于第5步的原理来找出每个采样点的最终top holder:
比如如下SQL列出了每个采样点top 2的blocker session,并且计算了其最终阻塞的session数(参考blocking_session_count)

select t.lv,
       t.iscycle,
       t.dbid,
       t.sample_id,
       t.sample_time,
       t.instance_number,
       t.session_id,
       t.sql_id,
       t.session_type,
       t.event,
       t.seq#,
       t.session_state,
       t.blocking_inst_id,
       t.blocking_session,
       t.blocking_session_status,
       t.c blocking_session_count
  from (select t.*,
               row_number() over(partition by dbid, instance_number, sample_time order by c desc) r
          from (select t.*,
                       count(*) over(partition by dbid, instance_number, sample_time, session_id) c,
                       row_number() over(partition by dbid, instance_number, sample_time, session_id order by 1) r1
                  from (select /*+ parallel 8 */
                         level              lv,
                         connect_by_isleaf  isleaf,
                         connect_by_iscycle iscycle,
                         t.*
                          from m_ash t
                        /*where sample_time >
                            to_timestamp('2013-11-17 13:55:00',
                                         'yyyy-mm-dd hh24:mi:ss')
                        and sample_time <
                            to_timestamp('2013-11-17 14:10:00',
                                         'yyyy-mm-dd hh24:mi:ss')*/
                         start with blocking_session is not null
                        connect by nocycle
                         prior dbid = dbid
                               and prior sample_time = sample_time
                                  /*and ((prior sample_time) - sample_time between interval '-1'
                                  second and interval '1' second)*/
                               and prior blocking_inst_id = instance_number
                               and prior blocking_session = session_id
                               and prior
                                    blocking_session_serial# = session_serial#) t
                 where t.isleaf = 1) t
         where r1 = 1) t
 where r < 3
 order by dbid, sample_time, r;

SAMPLE_TIME    INSTANCE_NUMBER    SESSION_ID    SQL_ID    EVENT    SEQ#    SESSION_STATE    BLOCKING_SESSION_STATUS    BLOCKING_SESSION_COUNT
22:03:32.116    1    1136    1p4vyw2jan43d    SGA:    1140    WAITING    UNKNOWN    82
22:03:32.116    1    413    9g51p4bt1n7kz    SGA:    7646    WAITING    UNKNOWN    2
22:03:42.226    1    1136    1p4vyw2jan43d    SGA:    1645    WAITING    UNKNOWN    154
22:03:42.226    1    537    3ajt2htrmb83y    SGA:    48412    WAITING    UNKNOWN    4
22:03:52.326    1    1136    1p4vyw2jan43d    SGA:    2150    WAITING    UNKNOWN    165
22:03:52.326    1    537    3ajt2htrmb83y    SGA:    48917    WAITING    UNKNOWN    8
22:04:02.446    1    1136    1p4vyw2jan43d    SGA:    2656    WAITING    UNKNOWN    184
22:04:02.446    1    537    3ajt2htrmb83y    SGA:    49423    WAITING    UNKNOWN    10
22:04:12.566    1    1136    1p4vyw2jan43d    SGA:    3162    WAITING    UNKNOWN    187
22:04:12.566    1    2472        SGA:    1421    WAITING    UNKNOWN    15
22:04:22.666    1    1136    1p4vyw2jan43d    SGA:    3667    WAITING    UNKNOWN    193
22:04:22.666    1    2472        SGA:    1926    WAITING    UNKNOWN    25
22:04:32.846    1    1136    1p4vyw2jan43d    SGA:    4176    WAITING    UNKNOWN    196
22:04:32.846    1    2472        SGA:    2434    WAITING    UNKNOWN    48

注意以上输出,比如第一行,代表在22:03:32.116,节点1的session 1136最终阻塞了82个session.  顺着时间往下看,可见节点1的session 1136是问题期间最严重的holder,它在每个采样点都阻塞了100多个session,并且它持续等待SGA: allocation forcing component growth,注意观察其seq#您会发现该event的seq#在不断变化,表明该session并未完全hang住,由于时间正好发生在夜间22:00左右,这显然是由于自动收集统计信息job导致shared memory resize造成,因此可以结合Scheduler/MMAN/MMNL的trace以及dba_hist_memory_resize_ops的输出进一步确定问题。

注意:
1) blocking_session_count 指某一个holder最终阻塞的session数,比如 a <- b<- c (a被b阻塞,b又被c阻塞),只计算c阻塞了1个session,因为中间的b可能在不同的阻塞链中发生重复。
2) 如果最终的holder没有被ash采样(一般因为该holder处于空闲),比如 a<- c 并且b<- c (a被c阻塞,并且b也被c阻塞),但是c没有采样,那么以上脚本无法将c统计到最终holder里,这可能会导致一些遗漏。
3) 注意比较blocking_session_count的数量与第3步查询的每个采样点的总session_count数,如果每个采样点的blocking_session_count数远小于总session_count数,那表明大部分session并未记载holder,因此本查询的结果并不能代表什么。
4) 在Oracle 10g中,ASH并没有blocking_inst_id列,在以上所有的脚本中,您只需要去掉该列即可。因此10g的ASH一般只能用于诊断单节点的问题。

其他关于ASH的应用
除了通过ASH数据来找holder以外,我们还能用它来获取很多信息(基于数据库版本有所不同):
比如通过PGA_ALLOCATED列来计算每个采样点的最大PGA,合计PGA以分析ora-4030/Memory Swap相关问题;
通过TEMP_SPACE_ALLOCATED列来分析临时表空间使用情况;
通过IN_PARSE/IN_HARD_PARSE/IN_SQL_EXECUTION列来分析SQL处于parse还是执行阶段;
通过CURRENT_OBJ#/CURRENT_FILE#/CURRENT_BLOCK#来确定I/O相关等待发生的对象

2015年4月PSU已经发布


2015年4月PSU已经发布,查看不同版本对应的patch信息,请参考:





更详细信息,请参考:


星期一 四月 13, 2015

原厂免费中文网上讲座: Oracle Dataguard12c 新特性

题目: Oracle数据库12c - Dataguard新特性 (Oracle Database 12c - Dataguard New Features)

简介: 这个1小时的网上研讨会,建议有Dataguard知识的DBA参加。在本次讲座中,我们将帮助DBA 了解Dataguard 12c新特性,比如:FAR SYNC/FAST SYNC Standby 数据库,使用12c switchover命令进行简化的switchover,Dataguard Broker的12c新特性(DGMGRL)。包括:

- Far SYNC/Fast SYNC Standby 介绍
- 使用12c switchover命令进行switchover和switchback
- Cascaded Standby的新特性

时间: 2015年5月21日(周四)2:00 pm

注册地址: https://oracleaw.webex.com/oracleaw/onstage/g.php?d=597971994&t=a

所有webcast的时间安排和过去的演讲pdf文稿和录像,可以在文档 Note 740966.1中找到。WebEx Conference 的接入细节:

Topic: Oracle数据库12c - Dataguard新特性 (Oracle Database 12c - Dataguard New Features) - Mandarin only
Event Number: 597 971 994
Event Passcode: 909090

一旦你的请求被批准,你将会收到一封邮件,告诉你更详细的加入这个会议的细节。

电话接入的方法:

- 中国北方地区免费接入号码: 108007130924
- 中国南方地区免费接入号码: 108001300748
- 中国台湾地区免费接入号码: 00801148720
Conference ID: 6755827

你可以在文档1148600.1中找到更多地区的免费电话号码. WebEx Conference本身也包含声音流,所以不一定要拨打电话来收听。

论坛讨论贴为:https://community.oracle.com/thread/3694468

星期三 四月 08, 2015

产品新闻 – Oracle TimesTen 新发布支持 SUSE 12 和 HP-UX Itanium 平台


星期四 – 2015年四月八日

最近,在最新发布的 Oracle TimesTen 内存数据库中,我们增加了对两个新的操作系统平台的支持:

•    TimesTen 11.2.2.8.0 经过认证可以运行在 SUSE Linux Enterprise Server 12操作系统平台上 (下载相同的 Linux X86-64 位软件即可)
•    TimesTen 11.2.2.8.1 经过认证可以运行在 HP-UX Itanium (v11.31) 操作系统平台上

TimesTen内存数据库新版本可以通过Oracle OTN 技术支持网站进行软件下载
http://support.oracle.com

原文链接:https://blogs.oracle.com/TimesTen/entry/product_news_on_suse_12

星期一 三月 30, 2015

Oracle数据库技术支持通讯2015年3月版(2015年3月)

Oracle数据库技术支持通讯2015年3月版已发布.

您可以收藏或访问 Note 1529795.1 来阅读最新内容,它包含了当前的技术通讯和历史版本的链接。


星期三 三月 25, 2015

产品新闻 – TimesTen 11.2.2.8.0



最新的TimesTen发行版本 11.2.2.8.0于2015年一月底发布,是一款面向所有支持平台的版本。
这里想介绍几个新的功能,可以提供显著的性能提升。


1.    显著提升并行复制吞吐量

对于使用OLTP应用程序,工作负载运行在非常高的交易速度,使用 TimesTen 的复制来实现高可用性的用户,相信你应该对该版本中新的复制功能产生兴趣。
如果您的复制配置当前正在使用的是单线程复制模式,你可能要考虑升级您的复制方案,采取自动并行复制(APR)功能,该功能在11.2.2.x版本中提供。 APR显著提升复制吞吐量 -从一个 TimesTen 的数据库复制到另一个远程主机上的 TimesTen 数据库的交易的速度。提升的变化取决于你的负载情况; 我们已经见过提升2至3倍复制事务速率的情况。自动并行复制既支持使用 Active-Standby Pair 复制策略下的同步 2-Safe 也支持异步复制的模式。

当自动并行复制功能被启用,事务依赖关系自动被追踪,当事务在远程备用数据库中应用时,事务提交顺序被遵从。启用并行复制不需要对应用做任何改变,并且复制并行度的设定是用户指定的配置。该参数名称为 ReplicationParallelism,将其设置为一个大于一(1)的值,以实现并行复制。

许多的OLTP应用具有彼此独立的事务处理。例如,你的账户扣除余额与扣除我的账户余额之间是独立的;你的移动设备的更新位置与我的设备的位置是独立的。 对于这样的应用程序,它通常是没有必要在使用复制的高可用性时,使用相同的提交顺序来应用这些事务。

在11.2.2.8.0版本,在接收主机上,当 TimesTen 决定交易对对方没有依赖关系时,放宽强制的提交顺序,用户可以启用新的并行复制功能。 该功能当应用复制事务到 Standby 库以及 Subscriber 数据库时,提供了甚至更多的并行性。根据您的交易工作负载的特点,我们曾经看到过在放宽备用数据库提交顺序后,有接近80% 的复制吞吐量的提升。为了放宽接收主机上的顺序,设置属性 ReplicationApplyOrdering 值为2。

在复制环境中,复制变化率的能力是很重要的,因为如果你有一个故障转移,变更被复制的速度决定了你的 Standby 数据库与 Active 数据库是何种紧密同步关系。理想的情况下,如果选择使用异步复制它们应该是相同的,或尽可能接近。
请参阅 TimesTen 复制文档了解更多信息。

2.    减少数据库的重启时间就使用对数据库检查点文件的并行读操作

在11.2.2.8.0 发行版本中,用户可以通过启用并行线程来读取 TimesTen 数据库检查点文件来减少他们的数据库重新启动时间。对于检查点文件比较大的,并驻留在固态或闪存情况下是非常有用的。

并行检查点读功能,通过设置新的 CkptReadThreads 属性来启用。 CkptReadThreads 是一个第一连接属性,并应在加载数据库前预先设置。该属性值指定,在加载数据库到内存时,TimesTen 用于读取检查点文件的线程数。

CkptReadThreads的默认值设置为1(通常用于硬盘存储)。当使用固态驱动器或闪存时,用户可以设置 CkptReadThreads 属性的值从2至8。从 SSD / 闪存的总体读取速率最好是通过将该属性设置为4和8之间的值实现。实际性能可能会根据设备型号不同而不同。

采用目前这一代SSD和闪存与8位并行检查点读线程,使用单个SSD设备或PCIe闪存卡,它可以达到2 GB /秒的读取速度。还可以通过使用双 SSD 设备 / 闪存卡(通过磁盘条带化)来实现3.4 GB /秒的持续读取速度。这意味着,一个大小为1TB的TimesTen数据库被加载到内存中大概仅仅需要5分钟。

为了提高数据库的重启时间,可以考虑对你的 TimesTe n检查点文件使用 SSD / 闪存设备,并启用并行检查点读功能。

星期三 三月 04, 2015

又有新的数据库中文文档添加到 My Oracle Support 中了! (2015年3月)

又有新的数据库中文文档添加到 My Oracle Support 中了!



最新翻译的文档列表:



Note 1985051.1 在 SLES 11 上安装 64位 Oracle Database 12.1 的要求

Note 1985005.1 如何将一个普通的非分区表进行分区

Note 1985042.1 在可插拔数据库上如何监控进程内存的使用

Note 1985032.1 11.2.0.4 上需要注意的 Performance 与 Wrong Results 问题

Note 1985045.1 SQL 版本数过高 – 原因判断脚本

Note 1984565.1 Software Patch Level 及 12C GI 的 OCR 备份/恢复

Note 1983660.1 Oracle Hang 管理器

Note 1602033.1 RACcheck - RAC 配置审计工具

Note 1984554.1 关于 RMAN 对于可插拔数据库按时间点的恢复

Note 1983639.1 如何利用 RMAN 可传输表空间迁移数据库到不同字节序的平台

Note 1986180.1 通过 RMAN 命令行查询用户表碰到 ora-1031 错误



完整的列表请点击这里

或登录 My Oracle Support  并查找:



中文文档列表 - Oracle Database (文档 ID 1533057.1)

星期三 十二月 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数据库产品技术支持-博客文章索引


星期二 十二月 02, 2014

ASM管理 - 如何重命名diskgroup

ASM 11.2.0.1 版本开始增加了diskgroup重命名的新功能,通过renamedg命令重命名已经创建的diskgroup,重命名前需要先dismount diskgroup。

如果重命名的diskgroup已经用于存储数据库的数据文件,那么需要手动同步数据文件的位置。



--检查ASM diskgroup当前名字为DGASMDB

$ su - grid

$ sqlplus / as sysasm

SQL> select GROUP_NUMBER,name,state,type, offline_disks, ALLOCATION_UNIT_SIZE,BLOCK_SIZE,TOTAL_MB,FREE_MB from v$asm_diskgroup;



GROUP_NUMBER NAME       STATE    TYPE   OFFLINE_DISKS ALLOCATION_UNIT_SIZE BLOCK_SIZE   TOTAL_MB    FREE_MB

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

           1 DGASMDB    MOUNTED  EXTERN             0              1048576       4096       3992       1879



--检查数据库当前信息(spfile/controlfile/datafile/redo)

su - oracle

$ sqlplus / as sysdba

SQL> show parameter spfile;

NAME                                 TYPE        VALUE

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

spfile                               string      +DGASMDB/asmdb/spfileasmdb.ora



SQL> show parameter control  

NAME                                 TYPE        VALUE

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

control_files                        string      +DGASMDB/asmdb/controlfile/current.256.856653049


SQL> select name from v$datafile;

NAME

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

+DGASMDB/asmdb/datafile/system.260.856653053

+DGASMDB/asmdb/datafile/sysaux.261.856653059

+DGASMDB/asmdb/datafile/undotbs1.262.856653061

+DGASMDB/asmdb/datafile/users.264.856653075

+DGASMDB/asmdb/datafile/asm_test.dbf



SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.





--dismount diskgroup dgasmdb

$ su - grid

$ asmcmd umount dgasmdb



--重命令diskgroup,新的diskgroup名为dgasmdb_new

$ renamedg phase=both dgname=dgasmdb newdgname=dgasmdb_new verbose=true  



Parsing parameters..

Parameters in effect:



         Old DG name       : DGASMDB 

         New DG name          : DGASMDB_NEW 

         Phases               :

                 Phase 1

                 Phase 2

         Discovery str        : (null) 

         Clean              : TRUE

         Raw only           : TRUE

renamedg operation: phase=both dgname=dgasmdb newdgname=dgasmdb_new verbose=true

Executing phase 1

Discovering the group

Performing discovery with string:

Identified disk ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so:ORCL:ASMDISK4G1 with disk number:0 and timestamp (33006423 142494720)

Checking for hearbeat...

Re-discovering the group

Performing discovery with string:

Identified disk ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so:ORCL:ASMDISK4G1 with disk number:0 and timestamp (33006423 142494720)

Checking if the diskgroup is mounted or used by CSS 

Checking disk number:0

Generating configuration file..

Completed phase 1

Executing phase 2

Looking for ORCL:ASMDISK4G1

Modifying the header

Completed phase 2

Terminating kgfd context 0x7fa6c2bee0a0





--mount新的diksgroup dgasmdb_new

$ asmcmd mount dgasmdb_new





--查看新的diskgroup信息

SQL> select GROUP_NUMBER,name,state,type, offline_disks, ALLOCATION_UNIT_SIZE,BLOCK_SIZE,TOTAL_MB,FREE_MB from v$asm_diskgroup;

GROUP_NUMBER NAME       STATE    TYPE   OFFLINE_DISKS ALLOCATION_UNIT_SIZE BLOCK_SIZE   TOTAL_MB    FREE_MB

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

           1 DGASMDB_NEW MOUNTED  EXTERN             0              1048576       4096       3992       1879




--修改DB 初始化参数(/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initasmdb.ora)配置信息

原来:SPFILE='+DGASMDB/asmdb/spfileasmdb.ora'

修改后:SPFILE='+DGASMDB_NEW/asmdb/spfileasmdb.ora'





--启动数据库nomount

su - oracle

sqlplus / as sysdba

startup nomount;





--修改control_files参数:

SQL> alter system set control_files='+DGASMDB_NEW/asmdb/controlfile/current.256.856653049' scope=spfile;

SQL> shutdown immediate;

SQL> startup mount;

SQL> show parameter control_files

NAME                                 TYPE        VALUE

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

control_files                        string      +DGASMDB_NEW/asmdb/controlfile

                                                 /current.256.856653049



--确认当前记录的datafile还是位于原来diskgroup DGASMDB

SQL> select FILE#,name from v$datafile;

     FILE# NAME

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

         1 +DGASMDB/asmdb/datafile/system.260.856653053

         2 +DGASMDB/asmdb/datafile/sysaux.261.856653059

         3 +DGASMDB/asmdb/datafile/undotbs1.262.856653061

         4 +DGASMDB/asmdb/datafile/users.264.856653075

         5 +DGASMDB/asmdb/datafile/asm_test.dbf



SQL> select file#, name from v$tempfile;

     FILE# NAME

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

         1 +DGASMDB/asmdb/tempfile/temp.263.856653061



--修改datafile/tempfile位置:

SQL> conn / as sysdba

SQL> ALTER DATABASE RENAME FILE '+DGASMDB/asmdb/datafile/system.260.856653053' TO '+DGASMDB_NEW/asmdb/datafile/system.260.856653053';

SQL> ALTER DATABASE RENAME FILE '+DGASMDB/asmdb/datafile/sysaux.261.856653059' TO '+DGASMDB_NEW/asmdb/datafile/sysaux.261.856653059';

SQL> ALTER DATABASE RENAME FILE '+DGASMDB/asmdb/datafile/undotbs1.262.856653061' TO '+DGASMDB_NEW/asmdb/datafile/undotbs1.262.856653061';

SQL> ALTER DATABASE RENAME FILE '+DGASMDB/asmdb/datafile/users.264.856653075' TO '+DGASMDB_NEW/asmdb/datafile/users.264.856653075';

SQL> ALTER DATABASE RENAME FILE '+DGASMDB/asmdb/datafile/asm_test.dbf' TO '+DGASMDB_NEW/asmdb/datafile/asm_test.dbf';

SQL> ALTER DATABASE RENAME FILE '+DGASMDB/asmdb/tempfile/temp.263.856653061' TO '+DGASMDB_NEW/asmdb/tempfile/temp.263.856653061';




--修改后确认:

SQL> select FILE#,name from v$datafile;

     FILE# NAME

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

         1 +DGASMDB_NEW/asmdb/datafile/system.260.856653053

         2 +DGASMDB_NEW/asmdb/datafile/sysaux.261.856653059

         3 +DGASMDB_NEW/asmdb/datafile/undotbs1.262.856653061

         4 +DGASMDB_NEW/asmdb/datafile/users.264.856653075

         5 +DGASMDB_NEW/asmdb/datafile/asm_test.dbf



--修改redo log位置

alter database rename file '+DGASMDB/asmdb/onlinelog/group_1.257.856653049' to '+DGASMDB_NEW/asmdb/onlinelog/group_1.257.856653049';

alter database rename file '+DGASMDB/asmdb/onlinelog/group_2.258.856653051' to '+DGASMDB_NEW/asmdb/onlinelog/group_2.258.856653051';

alter database rename file '+DGASMDB/asmdb/onlinelog/group_3.259.856653051' to '+DGASMDB_NEW/asmdb/onlinelog/group_3.259.856653051';

select * from v$logfile;



--启动数据库

SQL> alter database open;  

星期五 十一月 28, 2014

又有新的数据库中文文档添加到 My Oracle Support 中了!(2014年11月)

最新翻译的文档列表:



Note 1945390.1 常见问题:Oracle Database 12.1 可查询的 patch inventory(Queryable Patch Inventory)

Note 1945307.1 如何理解 Timesten Cache User Session 在 Oracle 数据库内有 Enq - UL Contention 等待事件 

Note 1945782.1 不同 Oracle 版本的客户端/服务器互操作性支持矩阵 

Note 1946289.1 AL32UTF8/UTF8(Unicode)数据库字符集含义 

Note 1945306.1 请求软件物理介质邮寄或下载链接 

Note 1945367.1 使用 OUI 克隆一个已经存在的 Oracle12c 版本1(12.1.0.x)数据库软件 

Note 1945766.1 静默安装 Oracle Database 12.1 报告“Null,null,null” 错误 

Note 1945838.1 Clusterware 和 RAC 中的域名解析的配置校验和检查 

Note 1945849.1 R12c 新特性:RMAN 可插拔数据库的备份和恢复 

Note 1945862.1 关于 12c GI 安装过程中,如果使用 NFS 方式提供 ASM 磁盘, 出现 ORA-15018 ORA-15072 ORA-15080 错误 

Note 1946664.1 零宕机时间迁移 ASM 磁盘组到另一个 SAN/磁盘阵列/DAS 的准确步骤 

Note 1946668.1 如何在 RAC 集群或单机 ASM 环境中对已经存在的 Diskgroup 添加新磁盘(最佳实践) 

Note 1946678.1 安装 11gR2 Grid Infrastructure(CRS)失败的处理过程 





完整的列表请点击这里



或登录 My Oracle Support  并查找:



中文文档列表 - Oracle Database (文档 ID 1533057.1)

星期二 十一月 18, 2014

Oracle 12.1.0.2数据库发布新版本


2014年11月14日 Oracle 12.1.0.2数据库发布以下平台版本:



•HP-UX Itanium

•IBM AIX

•IBM Linux on System z





截至到目前Oracle 12.1.0.2数据库已经发布的平台包括:



•Linux x86-64

•Oracle Solaris SPARC (64-bit)

•Oracle Solaris x86-64 (64-bit)

•Microsoft Windows x64 (64-bit)

•HP-UX Itanium

•IBM AIX on POWER Systems

•IBM Linux on System z

星期五 十一月 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数据库产品技术支持-博客文章索引

About

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

Search

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