回答了这四个问题,少踩12c 多租户的好多坑

在ACOUG的年终大会上,我分享了一个主题,列举了使用Oracle 12c多租户的过程中可能遇到的各种坑,当你使用一个新产品或者新特性时,如果你不了解,就可能是使用中,陷入其中。

首先我们已经知道,Oracle 12c的多租户特性,允许在一个容器数据库中,创建多个PDB,这些PDB彼此隔离和独立,但是依赖CDB而存在。

问题一:PDB丢失一个文件数据库会如何?

现在请大家思考一个问题:如果某个PDB中,因为意外而丢失了一个数据文件,那么数据库会怎样?

目前我们涉及的版本包括:12.1.0.1.0 ,12.1.0.2.0,12.2.0.1.0

12.1.0.1.0版本

[oracle@12c01db oradata]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.1.0 Production on Fri Dec 2 15:35:36 2016 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to an idle instance. SQL> startup ORACLE instance started. Database mounted. SQL> alter database open; Database altered. SQL>alter pluggable database yhem open; Pluggable database altered.

移除PDB中的一个数据文件,模拟一次数据文件的损失:

SQL> ! mv /oradata/EYGLE/YHEM/datafile/o1_mf_users_d3zb3hpq_.dbf /oradata/EYGLE/YHEM/datafile/o1_mf_users_d3zb3hpq_.dbf.bak

然后执行检查点,让数据库意识到这个损失:

SQL> alter system checkpoint; alter system checkpoint * ERROR at line 1: ORA-03113: end-of-file on communication channel Process ID: 23337 Session ID: 1 Serial number: 5

我们注意到进程终端,事实上整个数据库都崩溃了:

Fri Dec 02 15:35:12 2016 Errors in file /u01/app/oracle/diag/rdbms/eygle/eygle/trace/eygle_ckpt_23049.trc: ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode ORA-01116: error in opening database file 8 ORA-01110: data file 8: '/u01/app/oracle/oradata/EYGLE/YHEM/datafile/o1_mf_users_d3zb3hpq_.dbf' ORA-27041: unable to open file Linux-x86_64 Error: 2: No such file or directory Additional information: 3 Fri Dec 02 15:35:13 2016 USER (ospid: 23337): terminating the instance due to error 1242 Fri Dec 02 15:35:14 2016 Instance terminated by USER, pid = 23337

一个PDB里丢失了一个数据文件,崩溃了整个CDB,要知道CDB里可能有数十个或上百个PDB啊!要知道在12.1里多租户可以包含252个PDB,而12.2里可以包含4096的PDB。

这一切到底是为什么?

要想解释清楚这个问题,我们还要倒退一步,倒退到 Oracle 11.2.0.2 吧。

问题二:Oracle 11g 如何处理数据文件的丢失异常?

事情是这样的:

从Oracle 11.2.0.2版本开始,一个新的隐含参数 - _datafile_write_errors_crash_instance 被引入到数据库中,通过这个参数名就可以了解到其含义:当发生数据文件写错误时,Crash数据库实例。

为什么要引入这个参数呢?这个参数后台解决的是什么问题呢?

我在《数据安全警示录》一书上曾经写过多个案例,在归档模式下当发生文件(非SYSTEM文件)写错误时,Oracle会自动将数据文件离线,这造成了很多灾难,类似的错误日志可能是这样的:

Fri Jan 13 19:32:21 2013 KCF: write/open error block=0xf1fa6 online=1 file=73 /dev/rods_gm05 error=27063 txt: 'IBM AIX RISC System/6000 Error: 22: Invalid argument Additional information: -1 Additional information: 557056' Automatic datafile offline due to write error on file 73: /dev/rods_gm05

鉴于很多用户遇到的困境,Oracle做出了修正,这一修正在MOS上以BUG形式被提交,其内容为:Bug 7691270 Crash the DB in case of write errors (rather than just offline files) 。

在11.2.0.2之前,如果数据库运行在归档模式下,并且写错误发生在非SYSTEM表空间文件,则数据库会将发生错误的文件离线,在从11.2.0.2开始,数据库会Crash实例以替代Offline。注意:在非归档模式下或者SYSTEM遭受错误时,数据库会直接崩溃。

好了,现在答案清楚了:为了解决数据文件损失,离线控制存在的不确定性风险,Oracle引入的 _datafile_write_errors_crash_instance 控制数据库实例直接崩溃。

可是不要忘了,你现在是多租户啊,以前是一个人,可以任性,现在可是带队伍的了!这样不好吧?

问题三:PDB 能够以ABORT方式关闭么 ?

在Oracle 12c的考试中,有这样一道题目:

When executing shutdown abort in a pluggable database (PDB), you _____. A. shut down abort the CDB B. shut down abort the PDB C. shut down immediate the PDB D. shut down immediate the CDB

当我们通过shutdown abort的方式关闭PDB时,事实上我们做了什么?这个简单的题目,如果不加限定条件,答案是不确定的。

Oracle 12.1.0.1版本

通过10046的跟踪,可以清楚的找到事实真相:

[oracle@12c01db trace]$ sqlplus / as sysdba Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> select con_id,name,open_mode from v$pdbs; CON_ID NAME OPEN_MODE ---------- ---------------------- ---------- 2 PDB$SEED READ ONLY 3 YHEM MOUNTED SQL> alter pluggable database YHEM open; Pluggable database altered. SQL> alter session set container=YHEM; Session altered. SQL> alter session set events '10046 trace name context forever,level 12'; Session altered. SQL> shutdown immediate; Pluggable Database closed. SQL> exit Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options [oracle@12c01db trace]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.1.0 Production on Thu Dec 1 15:21:05 2016 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> alter session set container=YHEM; Session altered. SQL> startup Pluggable Database opened. SQL> alter session set events '10046 trace name context forever,level 12'; Session altered. SQL> shutdown abort; Pluggable Database closed.

对比两个跟踪文件,可以清晰的看到,在后台两种关闭方式事实上都被转换成immediate的方式关闭数据库,无论是归档模式还是非归档模式表现相同:

[oracle@12c01db trace]$ grep -i pluggable eygle_ora_14095.trc ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE [oracle@12c01db trace]$ grep -i pluggable eygle_ora_14115.trc ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE

在跟踪文件中的这一段代码如下:

===================== PARSING IN CURSOR #140136925772400 len=40 dep=0 uid=0 oct=227 lid=0 tim=67757313673 hv=1239515853 ad='9346b320' sqlid='65jadw14y30qd' ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE END OF STMT PARSE #140136925772400:c=0,e=215,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=67757313673 CLOSE #140136925778208:c=0,e=3,dep=1,type=0,tim=67757313767 =====================

在这个版本中的CDB中,标准的命令不包含ABORT选项:

SQL> alter pluggable database YHEM CLOSE; Pluggable database altered. SQL> alter pluggable database YHEM open; Pluggable database altered. SQL> alter pluggable database YHEM CLOSE ABORT; alter pluggable database YHEM CLOSE ABORT * ERROR at line 1: ORA-00922: missing or invalid option

所以在12.1.0.1版本中,这个问题的答案应该选择C。

看明白了么?也就是说,在Oracle 12.1.0.1版本中,Oracle根本就不支持PDB的异常关闭,所以Crash Instance,就只能Crash CDB的Instance了。

你一定会说:这不科学!是的,Oracle在不断修正和进化啊,所以不要害怕,我们看看 Oracle 12.1.0.2.0 版本中,发生了什么改变。

问题四:Oracle 的 PDB 能以ABORT的方式关闭么?

首先,必要要允许PDB Crash。

在Oracle 12.1.0.2.0 版本中,通过一个补丁修正 Bug 19001390 Oracle引入了两个隐含的初始化参数:

  • 第一个参数是: _enable_pdb_close_abort ,设置该参数,允许PDB异常关闭。
  • 第二个参数是:_enable_pdb_close_noarchivelog,允许PDB在非归档模式下异常关闭。

注意,不管是哪一种,如果异常关闭了PDB,又不能保留所有的归档日志,以后这个PDB可能永远也无法正常启动了。

Bug 19001390 的主题是:PDB system tablespace media failure causes the whole CDB to crash,在以下版本中被引入:

12.2 (Future Release) 12.1.0.2.1 (Oct 2014) Database Patch Set Update 12.1.0.2 Bundle Patch 1 (Oct 2014) for Engineered Systems / DB In-Memory (DBBP) 12.1.0.2 Patch 1 on Windows Platforms

我们看看以下测试,通过启用该参数,模拟之前的操作:

SQL> alter system set "_enable_pdb_close_abort"=true ; System altered. SQL> alter pluggable database PDBPROD1 open; Pluggable database altered. SQL> ! mv /oradata/PRODCDB/PDBPROD1/PDBPROD1_users01.dbf /oradata/PRODCDB/PDBPROD1/PDBPROD1_users01.dbf.bk SQL> alter system checkpoint; System altered. SQL> select con_id,name,open_mode from v$pdbs; CON_ID NAME OPEN_MODE ---------- ------------------------------- -------------------- 2 PDB$SEED READ ONLY 3 PDBPROD1 MOUNTED 4 PDBPROD2 READ WRITE

注意,此时告警日志输出如下,我们已经看到,现在PDB被单独的ABORT掉了,CDB和其他PDB未受到影响,这下科学了吧:

Fri Dec 02 15:58:39 2016 Errors in file /oracle/diag/rdbms/prodcdb/PRODCDB/trace/PRODCDB_ckpt_14527.trc: ORA-63999: data file suffered media failure ORA-01116: error in opening database file 10 ORA-01110: data file 10: '/oradata/PRODCDB/PDBPROD1/PDBPROD1_users01.dbf' ORA-27041: unable to open file Linux-x86_64 Error: 2: No such file or directory Additional information: 3 Fri Dec 02 15:58:43 2016 Internal PDB shutdown abort of PDBPROD1 (container=3)

当然,我们如果不想这个数据库崩溃,希望数据库回复到以前的效果,可以关闭11.2.0.2引入的参数:_datafile_write_errors_crash_instance,当该参数设置为FALSE之后,数据库将仅仅离线失去的数据文件:

Mon Jan 09 16:23:41 2017 Errors in file /oracle/diag/rdbms/prodcdb/PRODCDB/trace/PRODCDB_ckpt_13304.trc: ORA-01171: datafile 10 going offline due to error advancing checkpoint ORA-01116: error in opening database file 10 ORA-01110: data file 10: '/oradata/PRODCDB/PDBPROD1/PDBPROD1_users01.dbf' ORA-27041: unable to open file Linux-x86_64 Error: 2: No such file or directory Additional information: 3 Mon Jan 09 16:24:02 2017 Checker run found 1 new persistent data failures

我们注意到在12.2版本中的变化是:_enable_pdb_close_abort 参数的初始值被设置为TRUE,也就是缺省的,就只是异常关闭PDB,而不会影响整个CDB。

是不是觉得Oracle的世界又变得美好了?

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-01-18

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

job处理缓慢的性能问题排查与分析(r4笔记第18天)

昨天开发的同事找到我说,生产有个job处理数据的速度很慢,想让我帮忙看看是怎么回事,最近碰到这种问题相对比较多了,但是问题的原因也是五花八门。我还是大体找他们了...

2746
来自专栏沃趣科技

Oracle 12c系列(六)|Relocate a PDB

Relocating a PDB是Oracle在12C中推出的一种新的数据迁移方式,在采用Relocate时可以使用最短的停机时间在不同的CDB直接迁移PDB。

3257
来自专栏杨建荣的学习笔记

一个oracle bug的简单验证(r8笔记第45天)

最近碰到了一个oracle bug,但是我感觉还是有些运气的成分,虽然错误日志和bug描述吻合,版本也完全对应,现在有几个问题在我脑海中翻腾,就是这个问题是不是...

3477
来自专栏沃趣科技

Oracle 12c系列(五)|PDB Refresh

作者 杨禹航 出品 沃趣技术 PDB Refresh是12C推出的特性,具有对源端PDB进行增量同步的功能,每次刷新会将源端PDB中的任何更改同步到目标...

4126
来自专栏杨建荣的学习笔记

备库报警邮件的分析案例(三)(r7笔记第16天)

继前两篇分析了一个看似非常普通的报警邮件,结果在分析问题的时候八面玲珑,相关因素都给分析了一下,没想到还真是有不小的收获。 前两篇地址: 备库报警邮件的分析案例...

3095
来自专栏杨建荣的学习笔记

Data Guard高级玩法:通过闪回恢复switchover主库 (r10笔记第13天)

最近又试了下Data Guard的新玩法,可以通过闪回恢复switchover的主库,这种场景听起来比较特别,但是Oracle依旧支持。 我们的...

3127
来自专栏杨建荣的学习笔记

dg的奇怪问题终结和分区问题答疑 (r7笔记第77天)

今天来说几个问题,一个是对昨天《让我焦灼的四个问题》的升华,不能起博眼球的题目,技术分析给大家兜底了,你们看看有没有类似的问题。 还有几个小问题说说今天的感受和...

3355
来自专栏杨建荣的学习笔记

一个oracle查询引起的bug (r4笔记第59天)

任何软件都不是完美的,oracle也是如此,隔一段时间就会收到oracle的邮件说建议打哪些安全补丁什么的。新发布的产品都是release 1,比如10gR1...

3476
来自专栏杨建荣的学习笔记

三封报警邮件的分析(r6笔记第95天)

今天收到3封报警邮件,从邮件内容中的报警情况来看,还是比较反常的。需要引起关注,找到原因处理。 这个库是一个历史库,库中的数据非常庞大,几十亿数据的表还是有好几...

2584
来自专栏杨建荣的学习笔记

ADG备库批量查询失败的原因分析(r8笔记第33天)

目前线上有一套环境是10gR2的,采用了一主两备的架构。在其中一个备库上每天凌晨会开放一个窗口运行一些批量的查询,目前使用dg broker会在指定的时间把备库...

3428

扫描关注云+社区