星期四 五月 21, 2015

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

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

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



2015年5月版






星期三 四月 29, 2015

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

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

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



2015年4月版




产品新闻 – Oracle Enterprise Manager 插件新版本 TimesTen Plug-in 12.1.0.3.0


本月早些时候,Oracle 发布了Oracle Enterprise Manager 12c(企业管理器) 的插件新版本 TimesTen Plug-in 12.1.0.3.0。新版本为企业中的数据库管理员们带来很多新功能。

除了数据库的性能和可用性监控,新的插件为管理员们提供管理和维护他们的 TimesTen 实例和数据库的能力,例如启动和停止TimesTen 服务,装载数据库到内存和从内存中卸载数据库,调度备份和还原数据库。此外,用户可以监控数据库和复制活动,内存和磁盘的用量,工作负载性能统计,并确定运行时间最长,最常被执行的SQL语句。

国际用户将会很高兴的知道,新的 TimesTen 插件是全球化的,其用户界面支持九种不同的语言(包括支持中文界面),提供与 Oracle 企业管理器完全相同的语言。

TimesTen plug-in 12.1.0.3.0 是通过 Oracle 企业管理器自我更新(Self-Update)下载。

欲了解更多信息,请访问 Oracle 技术网络的 TimesTen 产品中心


Blog 由 SimonLaw-oracle 提供
原文链接:https://blogs.oracle.com/TimesTen/entry/new_timesten_plug_in_release

星期四 四月 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#

 order siblings by dbid, sample_time;


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的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

注册地址: 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)

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
      
今天