eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

February 12, 2019

Oracle 19c 新特性详解:DataGuard 中ADG的自动DML重定向

在前面的文章《Oracle 19c 十大新特性一览》中,我们曾经提到 Oracle 19c的一个重要增强,就是ADG的自动DML转发:

19c-7.jpg

这个新特性的功能是:将偶然发送到ADG上的DML操作,自动转发到主库执行,然后通过主库日志传递到备库实时应用,在保证了ACID的前提下,大大增强了备库的实用性,这被称为 DML Redirection 。

其实这个特性在 Oracle 18c 中就已经提供,所以我们不必等到 19c 就能够体验到这个特性。

在两个版本中,唯一的差别是:

在 18c 中,这个特性是通过隐含参数 _enable_proxy_adg_redirect 的调整来启用这个特性,这表示此特性是趋向内部的;

在 19c 中,显式参数 ADG_REDIRECT_DML 参数控制这个特性的开关,说明这个特性变成外部和成熟的;

来看一下测试,体验一下这个新特性的便利性。首先在主库建立测试表,插入测试数据:

[oracle@18.0.0]$ export ORACLE_SID=DB18C

[oracle@18.0.0]$ sqlplus / as sysdba

Connected to:

Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production

SQL> create user eygle identified by eygle;

User created.

SQL> grant connect,resource,dba to eygle;

Grant succeeded.

SQL> connect eygle/eygle

Connected.

SQL> create table enmotech (id number,name varchar2(20));

Table created.

SQL> insert into enmotech values(1,'EYGLE');

1 row created.

SQL> commit;

Commit complete.

SQL> select open_mode from v$database;

OPEN_MODE

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

READ WRITE

接下来在备库中就设置了参数之后,就可以针对表执行DML操作了,注意备库需要置于实时应用状态:

[oracle@18.0.0]$ export ORACLE_SID=DB18C_S

[oracle@18.0.0]$ sqlplus eygle/eygle

Connected to:

Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production

SQL> select open_mode from v$database;

OPEN_MODE

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

READ ONLY WITH APPLY

SQL> select * from enmotech;

ID NAME

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

1 EYGLE

SQL> alter session set "_enable_proxy_adg_redirect"=true;

Session altered.

SQL> show parameter redirect

NAME TYPE VALUE

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

_adg_redirect_flags integer 1

_enable_proxy_adg_redirect boolean TRUE

-- 此处启用跟踪,可以分析 ADG 重定向的工作原理

SQL> alter session set events '10046 trace name context forever ,level 12';

Session altered.

--此处的DML操作可以顺利执行

SQL> insert into enmotech values(2,'YANGTINGKUN');

1 row created.

SQL> select * from enmotech;

ID NAME

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

1 EYGLE

2 YANGTINGKUN

SQL> commit;

Commit complete.

在以上测试中,可以通过设置10046跟踪,以获得后台的递归执行,研究这个特性的工作原理。

也可以设置终端输出时间,评估重定向的延时,我的测试环境搭建在同一台主机,基本上DML操作的延时在1秒左右,偶发情况下是完全可以接受的:

SQL> set timing on

SQL> insert into enmotech values(2,'KAMUS');

1 row created.

Elapsed: 00:00:01.05

SQL> select * from enmotech;

ID NAME

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

1 EYGLE

2 YANGTINGKUN

2 KAMUS

Elapsed: 00:00:00.00

SQL> commit;

Commit complete.

Elapsed: 00:00:01.05

通过后台的跟踪日志,可以看到,DML操作是通过DB Link来重定向到主库执行的,这个DB Link是内部的,在服务名等配置正常情况下,Oracle能够自动完成内部操作,如果配置错误则会出现错误:

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

PARSING IN CURSOR #139880746795960 len=44 dep=0 uid=107 oct=2 lid=107 tim=45368825051292 hv=3193100945 ad='674870e8' sqlid='3bg4wy2z55qnj'

insert into enmotech values(2,'YANGTINGKUN')

END OF STMT

PARSE #139880746795960:c=44993,e=1721825,p=1,cr=28,cu=6,mis=1,r=0,dep=0,og=1,plh=0

WAIT #139880746795960: nam='SQL*Net message to dblink' ela= 2

WAIT #139880746795960: nam='SQL*Net message from dblink' ela= 1164

EXEC #139880746795960:c=1000,e=1297,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,plh=0

WAIT #139880746795960: nam='SQL*Net message to dblink' ela= 1

WAIT #139880746795960: nam='SQL*Net vector data to dblink' ela= 82

WAIT #139880746795960: nam='SQL*Net message from dblink' ela= 1280

*** 2019-01-10T21:08:37.292860+08:00

WAIT #139880746795960: nam='standby query scn advance' ela= 850283

WAIT #139880746795960: nam='PGA memory operation' ela= 98 p1=0 p2=0

WAIT #139880746795960: nam='SQL*Net message to client' ela= 2 d

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

PARSING IN CURSOR #139880746795960 len=6 dep=0 uid=107 oct=44 lid=107 tim=45368881823728 hv=3480936638 ad='0' sqlid='23wm3kz7rps5y'

commit

END OF STMT

PARSE #139880746795960:c=0,e=150,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0

XCTEND rlbk=0, rd_only=1, tim=45368881823795

WAIT #139880746795960: nam='SQL*Net message to dblink' ela= 2

WAIT #139880746795960: nam='SQL*Net message from dblink' ela= 1598

*** 2019-01-10T21:09:34.259699+08:00

WAIT #139880746795960: nam='standby query scn advance' ela= 1045191

EXEC #139880746795960:c=1000,e=1047570,p=0,cr=0,cu=4,mis=0,r=0,dep=0,og=0,plh=0

WAIT #139880746795960: nam='SQL*Net message to client' ela= 3

除了常规表之外,Oracle 还支持在备库创建全局临时表,在19c中,隐含参数 _alter_adg_redirect_behavior 可以用于定义允许重定向的级别,例如当设置 disallow_gtt 将不允许重定向全局临时表

ADG 中 DML 重定向新特性带来的另外一个问题时,以后部署ADG时,必须注意备库安全管控,否则滥发到备库的DML可能损害主库的一致性。

这些变化告诉我们的是:时移世易,当新的版本和特性被引入时,一定会带来新的变化,如果不能及时了解这些变化,在享受便利的情况下,就可能面临意外的风险

Posted by eygle at 9:46 PM | Permalink | Oracle12c/11g (151)

January 17, 2019

Oracle 比率:Redo Nowait Ratio 的计算方式

有朋友问道这个问题,在 AWR 中,Redo Nowait 比例的含义。在很多报告中,这个值出现了负数。

其实从 Statspack 的报告中,就可以找到计算公式:

--
--  Instance Efficiency Percentages

column ldscr  format a50

column nl format a60 newline;
select 'Instance Efficiency Percentages (Target 100%)' ldscr
      ,'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' ldscr
      ,'            Buffer Nowait %:'                  dscr
      , round(100*(1-:bfwt/:gets),2)                   pctval
      ,'      Redo NoWait %:'     
      , decode(:rent,0,to_number(null), round(100*(1-:rlsr/:rent),2))  pctval
      ,'            Buffer  Hit   %:'                  dscr
      , round(100*(1-(:phyr-:phyrd-:phyrdl)/:gets),2) pctval
      ,'   In-memory Sort %:'     
      , decode((:srtm+:srtd),0,to_number(null),
                               round(100*:srtm/(:srtd+:srtm),2))       pctval
      ,'            Library Hit   %:'                  dscr
      , round(100*:lhtr,2)                             pctval
      ,'       Soft Parse %:'     
      , round(100*(1-:hprs/:prse),2)                   pctval
      ,'         Execute to Parse %:'                  dscr
      , round(100*(1-:prse/:exe),2)                    pctval
      ,'        Latch Hit %:'     
      , round(100*(1-:lhr),2)                          pctval
      ,'Parse CPU to Parse Elapsd %:'                  dscr
      , decode(:prsela, 0, to_number(null)
                      , round(100*:prscpu/:prsela,2))  pctval
      ,'    % Non-Parse CPU:'
      , decode(:tcpu, 0, to_number(null)
                    , round(100*1-(:prscpu/:tcpu),2))  pctval
  from sys.dual;

这其中能够看到很多比率的计算方式,Nowait Redo 的计算如下:
decode(:rent,0,to_number(null), round(100*(1-:rlsr/:rent),2))  pctval

这其中:
rlsr = Redo Log space requests
rent = Redo Entries

有了这个计算公式,就可以理解其中的玄机了。如果 Redo Log Space 的请求非常多,这个计算就可能出现负数,或者 rent 溢出变小都是可能的情况。

Posted by eygle at 9:46 PM | Permalink | FAQ (257)

January 16, 2019

Oracle 12.2 DBCA 使用 Silent 建库

许久没有用 Silent 方式建库了,非常顺畅,建立一个 12.2 非多租户的数据库:

[oracle12c@iz2zeezinabu7k6olgelwez ~]$ dbca -silent -createDatabase \

> -templateName General_Purpose.dbc \

> -gdbname eygle -sid eygle -responseFile NO_VALUE \

> -characterSet AL32UTF8 \

> -sysPassword OraPasswd1 \

> -systemPassword OraPasswd1 \

> -createAsContainerDatabase false \

> -databaseType MULTIPURPOSE \

> -automaticMemoryManagement false \

> -totalMemory 1536 \

> -storageType FS \

> -datafileDestination "/u01/oracle12c/db/oradata/" \

> -redoLogFileSize 50 \

> -emConfiguration NONE \

> -ignorePreReqs

[WARNING] [DBT-11207] Specified SGA size is greater than the shmmax on the system. This might make database creation to fail with ORA-27125 - Unable to create shared memory segment error.

ACTION: Specify SGA size lesser than or equal to the shmmax on the system.

Copying database files

1% complete

2% complete

18% complete

33% complete

Creating and starting Oracle instance

35% complete

40% complete

44% complete

49% complete

50% complete

53% complete

55% complete

Completing Database Creation

56% complete

57% complete

58% complete

62% complete

65% complete

66% complete

Executing Post Configuration Actions

100% complete

Look at the log file "/u01/oracle12c/db/cfgtoollogs/dbca/eygle/eygle.log" for further details.

如果是多租户,增加几个参数,类似如下:

dbca -silent -createDatabase \
-templateName General_Purpose.dbc \
-gdbname cdb01 -sid cdb01 -responseFile NO_VALUE \
-characterSet AL32UTF8 \
-sysPassword OraPasswd1 \
-systemPassword OraPasswd1 \
-createAsContainerDatabase true \
-numberOfPDBs 1 \
-pdbName pdb3 \
-pdbAdminPassword OraPasswd1 \
-databaseType MULTIPURPOSE \
-automaticMemoryManagement false \
-totalMemory 1536 \
-storageType FS \
-datafileDestination "/u01/app/oracle/oradata/" \
-redoLogFileSize 50 \
-emConfiguration NONE \
-ignorePreReqs

操作很简单.

Posted by eygle at 9:16 PM | Permalink | Oracle12c/11g (151)

December 26, 2018

Oracle Database 19c 的发布时间确定和升级建议

很多朋友问我,Oracle 19c的发布时间,以及升级建议。

我们先来看升级建议,Oracle 18c = 12.2.0.2 ,Oracle 19c = 12.2.0.3,Oracle 19c 将是原有序列的12c最后一个版本,如果您现在还没有升级到12c,那么可以选择等待一步到位升级到 19c ,18c 作为一个过度的版本,不建议空降到这个版本序列。如果您之前使用的版本是 12.2.0.1,那么升级到 18c 是可以的。

那么问题是:Oracle 19c的发布时间是什么时候

在MOS上,12月最近刚刚更新的信息显示,19c的发布时间为 Q1CY9,也就是2019年第一季度。

参考:

Thumbnail image for oracle11gESsupport.jpg

该文档同时给出了,相关版本的升级支持,11.2.0.4 、12.1.0.2、12.2.0.1、18c 都可以直接升级到 19c 版本:Thumbnail image for PIC.jpg

以上信息,仅供参考。

Posted by eygle at 2:27 PM | Permalink | OraNews (253)

December 25, 2018

Oracle 11g于2019年1月1日结束支持-进入付费扩展支持期

Oracle 官方产品支持周期已经做出提示,Oracle 数据库的 11g版本,将于2019年1月1日进入扩展服务付费支持期

扩展服务支持简单来说就是必须要额外付费才能获得支持,原本2015年开始Oracle 11g就进入了扩展服务支持期,Oracle豁免了服务费,但是自2019年1月1日起,正是进入需要额外付费的扩展支持期了。

如下图所示,第一行最后深红色部分,就是需要付费的扩展服务阶段,必须要和Oracle签订扩展服务支持合同才能够继续获得11g的后续支持。考虑到中国企业购买ES支持的比例,我们可以认为11g的官方支持基本结束了。

oracle11gESsupport.jpg

上图第一行就是 11.2 版本的支持生命周期,已经长达11年了。同种还展示了 即将发布的Oracle 19c 支持计划。

预计将于 2019年第一季度发布的 19c 将是 Oracle 12c 的终极版本,相当于传统的 12.2.0.3 版本,按照管理,这个版本将会支持到 2026年。

在以下表格中,更加清晰的列出了时间表:

oraclesupportend.jpg

Oracle 11g的用户是时候考虑升级了。

Posted by eygle at 1:58 PM | Permalink | OraNews (253)

近期发表

  • 从ADG到自动索引创建:Oracle Database 19c 的10大新特性 - December 23, 2018
  • 2018 ACOUG年会:从BigData到Cloud,Oracle的云上变革 - December 22, 2018
  • Oracle 12c :ASM 存储单盘限制从2TB到4PB的改变 - December 17, 2018
  • Oracle 18c 19c 安装的 DBT-50000 错误解决 - November 28, 2018
  • 使用 DBMS_RESOURCE_MANAGER.CALIBRATE_IO 测试I/O性能 - November 6, 2018
  • Oracle 18c新特性:Oracle 18.3 RPM安装顺畅初体验 - October 21, 2018
  • Oracle 18c发布了传闻已久的 18.3 RPM 安装版本 - October 20, 2018
  • 慧据价值 链接未来丨第八届数据技术嘉年华大会盛大开启 - September 29, 2018
  • Oracle 的 X$ 表之:x$kqfta 内核SQL固定表信息 - September 16, 2018
  • 删库之后不要着急跑路,这本书可以救命(含电子书下载) - September 11, 2018


  • CopyRight © 2004 ~ 2012 eygle.com, All rights reserved.