星期四 七月 23, 2015

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

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

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



2015年7月版




星期五 六月 26, 2015

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

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

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





2015年6月版




星期二 六月 09, 2015

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

最新翻译的文档列表:



Note 2016372.1 在 Oracle Home 目录中重建Central Inventory(oraInventory)的步骤

Note 2016386.1 使用 DBUA 升级数据库到 Database 12c 版本 1(12.1)的完整核对清单

Note 2016783.1 如何检查补丁/软件下载的完整性? [视频]

Note 2016002.1 ORA-4031 错误故障排除与诊断[视频]

Note 2016782.1 统计信息自动收集的最佳实践

Note 2016355.1 恢复表的统计信息

Note 2016422.1 故障排除:"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! "

Note 2017246.1 对于诊断 Oracle Clusterware(CRS 或 GI)和 Real Application Cluster(RAC)问题的数据收集

Note 2016852.1 如何(Deconfigure)解除配置/(Reconfigure)重新配置(重建 OCR)或卸载 GI

Note 2017199.1 RMAN 在 Oracle 12c 的增强功能

Note 2017258.1 RMAN 备份保留策略的常见问题



完整的列表请点击这里



或登录 My Oracle Support  并查找:

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

星期二 六月 02, 2015

错误的用户名密码登录导致的数据库性能问题

背景:
从Oracle 11.1开始,错误的用户名密码登录可能会导致在数据库层面看到显著的“row cache lock”等待。
很多用户认为这是一个bug,而实际上这是一个数据库保护机制。
Oracle的sqlplus工具会在3次错误密码输入后自动断开连接,但是外部应用程序却可以编码,不断调用登录API进行密码尝试。所以如果没有一个数据库层面的安全控制,这将是非常危险的。
从Oracle 11.1开始,数据库会在对同一个用户3次错误的密码尝试之后,开始锁定这个用户3秒钟,才允许下一次登录。这个锁定时间将从3秒逐渐延长,不断增加。
所有以该用户登录的session都会等待“row cache lock”,哪怕他是用正确的密码登录的。

很多用户不理解这样做是为了帮助用户避免风险,而对看到的“row cache lock”等待提出抱怨。
所以Oracle在Bug 7715339的修复中提供了一个方法(event 28401)来绕过这段代码,来供用户做不同选择。
event="28401 trace name context forever, level 1" # disable logon delay
必须说明的是,这实际上并不是一个bug,而是一个功能增强。用户必须清楚如果设置了这个事件,将使您的数据库暴露在密码猜测的风险之下。

Bug 7715339的修复被包含在11.2.0.1 PSU之中。而在11.1.0.7上打补丁7715339,默认已经相当于打开event 28401了。
在11.2.0.2之后,Oracle修改代码,将这一段“row cache lock”等待修改成了“library cache lock”等待。
总结一下:
1)11.1.0.X上,错误的用户名密码登录,将导致显著的“row cache lock”等待。
用户可以在11.1.0.7上打补丁7715339,不用设置event 28401,就可绕过这段安全控制代码。
2)11.2.0.1上,错误的用户名密码登录,将导致显著的“row cache lock”等待。
用户不用打补丁(因为已经包含在11.2.0.1中了),直接设置event 28401,就可绕过这段安全控制代码。
3)11.2.0.2以上的版本(包含11.2.0.2),错误的用户名密码登录,将导致显著的“library cache lock”等待。
用户不用打补丁(因为已经包含在11.2.0.1中了),直接设置event 28401,就可绕过这段安全控制代码。

必须再次说明的是,用户必须清楚如果打补丁或者设置了这个事件,将使您的数据库暴露在密码猜测的风险之下。

正题:
有用户反馈,即使设置了event 28401,仍会观察到错误的用户名密码登录导致“library cache lock”等待,这是为什么呢?为此,我们做了以下测试进行说明:

起10个进程,同时进行错误的用户名密码登录,并测试未设置event 28401和设置event 28401进行比较,从V$SYSTEM_EVENT中多次观察获取平均等待时间:
select total_waits,Time_waited_fg/total_waits
from V$SYSTEM_EVENT
where event='library cache lock'

未设置event 28401:
91    1395.252747252747252747252747252747252747
98    2352.959183673469387755102040816326530612
106    2687.698113207547169811320754716981132075
116    3495.862068965517241379310344827586206897

<========library cache lock的平均等待时间很快从13.95秒逐渐增加到34.95秒,并且持续增加。

设置event 28401之后:
23142    2.97325209575663296171463140610146054792
24329    3.03592420568046364421061284886349623906

<========即使在24329次等待之后,library cache lock的平均等待时间仍然稳定在0.03秒。

也就是说,event 28401是生效的,“等待时间从3秒逐渐增加的”的安全机制被绕过了,但是“library cache lock”却无法避免。
这是因为,错误的用户名密码登录仍会在数据库内部更新该用户的登录次数,错误登录次数,上次登录时间等信息,需要申请“library cache lock”。
而“library cache lock”的等待时间跟并发登录的进程数和数据库性能有关。
如果有多个用户进行不断的进行错误的密码尝试,可能仍会观察到较高的“library cache lock”等待。
因为“错误的密码尝试”应用程序的代码逻辑一般都是非常疯狂的,正确的登录可能一次就过了,而一旦错误会反复尝试并且没有sleep等待,这将导致一秒钟可能会发起几百次上千次的尝试,
而多个进程并发时就容易观察到平均等待几十毫秒甚至几百毫秒的“library cache lock”了。因为会不断尝试,在数据库层面会累积而很容易观察到。
但是设置event 28401之后,一般不会有几十秒上百秒的单次等待了,因为单次递增的等待机制被绕过了。

总体来讲,数据库管理员应该尽快发现并解决错误的用户名密码登录问题(它们一般是因为数据库密码被更改而应用程序没有及时同步造成的),而不应该过度依赖event 28401。
因为无论从哪个角度来看,错误的用户名密码登录都是一个应用层面的异常问题,是应该被避免的。

星期一 六月 01, 2015

11gR2 RAC OCR磁盘组的换名重建恢复测试

11gR2 RAC OCR磁盘组的换名重建恢复测试


一、背景


根据文档1062983.1中的步骤恢复OCRreplace
voting disk
到新的磁盘组后,发现新磁盘组无法通过crsctl stat res -t查看。由于11gR2不支持srvctl add diskgroup目录,需要用crsctl add res ora.OCR.dg -type ora.diskgroup.type -file ocrdg.txt添加。


二、测试目的


删除虚拟机RACCRS物理磁盘后,使用OCR备份恢复到新的OCR磁盘组,看恢复后crsctl stat res –t是否可以列出新的OCR磁盘组,如果没有列出,手工增加磁盘组。


全文请下载附件(右键点击链接,“另存为”即可):11gR2 RAC OCR磁盘组的换名重建恢复测试





星期日 五月 31, 2015

使用VirtualBox搭建Windows8平台11.2.0.3 RAC并升级11.2.0.4

        目前,绝大多数RAC环境都是UNIX/Linux平台,但Windows RAC由于易操作性其数量在增加,而相应的文档却比较少。人们搭建RAC测试环境的最大障碍是共享存储。在生产环境中,共享存储通常有SAN或高端NAS设备提供,但这些选择非常昂贵,显然不适合用来搭建测试环境学习RAC。使用VirtualBox您可以在一个机器上运行多个虚拟机(VMs),并允许您创建虚拟的共享磁盘,免去了使用昂贵共享存储的开销。因此这里使用VBox来做Win RAC的安装和升级演示。


详细请下载附件(右键点击链接,“另存为”即可):


使用VirtualBox搭建Windows8平台11.2.0.3 RAC并升级11.2.0.4(1 of 2)


 使用VirtualBox搭建Windows8平台11.2.0.3 RAC并升级11.2.0.4(2 of 2)

星期四 五月 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 / 闪存设备,并启用并行检查点读功能。

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
21
22
24
25
26
27
28
29
30
31
 
       
今天