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

星期三 十月 15, 2014

2014年10月PSU已经发布(2014年10月)

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

Oracle Recommended Patches -- Oracle Database (Doc ID 756671.1)

星期二 十月 14, 2014

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

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

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

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

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

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

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



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

<=====sql: c000000cfdbef790

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

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

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

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

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

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

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

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

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

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



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


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


星期六 十月 11, 2014

Oracle诊断工具 - ORA-4030 Troubleshooting Tool



ORA-4030 说明Oracle服务器进程(server process)无法在操作系统(OS)上分配到足够的内存。



导致ORA-4030 的主要原因有:

-物理内存不足

-OS kernel/ulimit限制

-应用代码问题导致SQL使用大量内存

-Oracle bug



分析解决ORA-4030问题,Oracle support网站提供ORA-4030诊断工具:ORA-4030 Troubleshooting Tool

ORA-4030 Troubleshooting Tool根据分析上传的日志文件,提供ORA-4030的分析解决方案。

如果符合一个已知的问题,那么ORA-4030 Troubleshooting Tool提供错误原因和解决方案。

如果没有符合的已知问题,那么ORA-4030 Troubleshooting Tool会导向ORA-4030 master note,详细介绍ORA-4030错误。



使用ORA-4030 Troubleshooting Tool好处:

- 分析上传的文件后,对于一个已知的问题,提供错误的原因和解决方案。

- 如果没有已知问题,会导向ORA-4030 master note。

- 提供诊断分析报告。

- 可选择创建SR,会自动填入许多SR的项目。



访问ORA-4030 Troubleshooting Tool有2种方法:

方法1:创建SR时使用ORA-4030 Troubleshooting Tool

    步骤1:上传文件

    步骤2:浏览推荐

方法2: 直接访问ORA-4030 Troubleshooting Tool

    步骤1:分析新的问题

    步骤2:上传文件

    步骤3:浏览推荐

    步骤4:浏览诊断向导

了解更多ORA-4030介绍,请参考:

Master Note for Diagnosing OS Memory Problems and ORA-4030 (Doc ID 1088267.1)

Diagnosing and Resolving ORA-4030 errors (Doc ID 233869.1)

ORA-4030 PGA Usage Diagnostic Script [Video] (Doc ID 1087789.1)

ORA-4030 Troubleshooting Tool (Doc ID 1521926.1)

FAQ: ORA-4030 [Video] (Doc ID 399497.1)

参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"分享:Oracle诊断工具 - ORA-4030 Troubleshooting Tool"。



星期四 九月 18, 2014

RAC 性能分析 - ORA-29770 global enqueue process string (OSID string) is hung for more than string seconds



概述

-----

在11g版本之前,RAC数据库中一个实例无法与其他实例通信,数据库实例将会被集群驱逐(Evict),同时Alert Log伴随错误信息:ORA-29740: evicted by instance number string, group incarnation string



从11g版本开始,RAC数据库功能又有了显著的增强,例如增加了本地实例进程之间的状态监控,LMHB进程定时监控本实例中其他核心进程(LMON/LMD/LMS/LCK等)状态,如果LMHB发现核心进程在允许的时间内(默认70秒)没有响应,那么LMHB进程会重启该数据库实例,以防止问题影响到整个集群,同时Alert Log伴随错误信息ORA-29770。因此错误信息ORA-29770只是问题的结果而不是原因,分析问题原因需要检查LMHB trace文件。



下面是 Oracle 官方文档中关于ORA-29770的解释:

ORA-29770: global enqueue process string (OSID string) is hung for more than string seconds

Cause:     The specified process mades no progress within the maximum allowed time.

Action:    Check the alert file and relevent trace files and contact Oracle Support Services with the incident information.



常见原因

---------

• OS资源不足,导致进程无法正常工作。

无法获得数据库资源,导致进程一直处于等待状态。

进程处于ON CPU 或者 Spin 状态。



案例

--------

- 下面 Alert log 错误信息说明LMHB进程发现LMON进程在70秒时间内没有响应:



LMON (ospid: 62062756) waits for event 'control file sequential read' for 83 secs.

Errors in file /home/oracle/app/oracle/diag/rdbms/ora/ora1/trace/ora1_lmhb_62259296.trc  (incident=416304):

ORA-29770: global enqueue process LMON (OSID 62062756) is hung for more than 70 seconds

Incident details in: /home/oracle/app/oracle/diag/rdbms/ora/ora1/incident/incdir_416304/ora1_lmhb_62259296_i416304.trc

ERROR: Some process(s) is not making progress.

LMHB (ospid: 62259296) is terminating the instance.



- LMHB trace (ora1_lmhb_62259296.trc)错误信息说明LMON进程在等待IO,等待时间1分43秒超过了阀值70秒:



Current Wait Stack:

 0: waiting for 'control file sequential read'

    file#=0x0, block#=0x23, blocks=0x1

    wait_id=75328 seq_num=9829 snap_id=1

    wait times: snap=1 min 43 sec, exc=1 min 43 sec, total=1 min 43 sec

    wait times: max=infinite, heur=1 min 43 sec

    wait counts: calls=0 os=0

    in_wait=1 iflags=0x5a0



因此建议检查系统IO,另外,在11.2低版本中也有类似的已知问题会导致ORA-29770,建议安装最新patch set (11.2.0.4) 和最新PSU。Patch set和PSU信息请参考:Oracle Recommended Patches -- Oracle Database (Doc ID 756671.1)


参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"分享:RAC 性能分析 - ORA-29770"。 


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





About

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

Search

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