DBASK数据库提问平台问题集萃，首批近二十位专家团曝光

引言

---

最近注意到19C官方文档中部分视图已经没有了说明，MOS上很多文档也隐藏了起来，开源公司不断被资本收购，但是我们始终向往构建一个开放开源、互帮互助的社区环境，我们也再不断为之努力，平台上运维工具免费使用，资源共享下载，举办线上线下的活动，就在一个月前我们推出了DBASK数据库提问平台（点击“阅读原文”，马上提问题），当您遇到任何数据库疑难杂症都可在DBASK提问，平台认证专家免费在线解答。我们还开放了专家整理归档的知识库，供您免费学习和搜索排错。

小程序的发布可以让大家随时随地提问，专家也可在小程序内即时回复，减少了提问的门槛，加快问题交互的流程。另外可以在微信小程序中浏览知识库，方便查找学习相关问题。

使用指导

---

1. 微信小程序搜索DBASK，或微信直接扫描下方小程序码；

2. 首次进入需要微信授权，绑定手机号；

3. 热门问题 - 浏览学习专家归档的热门问答（可增加评论）；

4. 提交问题 - 输入问题描述和详情快速提交问题；

5. 我的问题 - 查看我提交的问题，更新问题（可上传图片）；

6. 专家回复问题后，会在微信内通知用户；

7. 添加到“我的小程序“，问答更方便。

常驻专家团

---

盖国强（Eygle）	Oracle ACE Director
张乐奕（Kamus）	Oracle ACE Director
李轶楠（ORA-600）	Oracle ACE
杨廷琨（Yangtingkun）	Oracle ACE Director，Oracle百科全书
熊军	Oracle ACE Director
侯圣文	Oracle ACE Director，OCM联盟创始人
Joel	Oracle ACE Director
李真旭（Roger）	Oracle ACE，精通开源数据库（MySQL，MongoDB等）
罗海雄	Oracle ACEA
张维照	Oracle ACE
姜劲松	擅长Oracle和SQL Server的性能优化和故障诊断
李华	擅长性能优化和各种疑难杂症处理
怀晓明	Troubleshooting，数据库、Web设计、开发，精于故障诊断和处理
刘伟	开源数据库（MySQL、PostgreSQL等）、分布式数据库资深研究员
崔虎龙	MySQL技术顾问，擅长MySQL、Redis、MongoDB设计、故障处理、恢复、升级优化等
......

接下来，我们分享本期整理出的精彩问答，供大家参考学习，防患于未然。

问题一、安装Grid执行root.sh报错ORA-27504

---

问题描述：

在centos7.4 64bit上安装oracle 12.2的grid执行root.sh报错如下：

ASM failed to start. Check /grid/app/grid/grid_base/cfgtoollogs/asmca/asmca-181205AM124153.log for details.
2018/12/05 13:42:18 CLSRSC-184: Configuration of ASM failed
2018/12/05 13:42:20 CLSRSC-258: Failed to configure and start ASM
Died at /grid/app/grid/grid_home/crs/install/crsinstall.pm line 2091.
The command '/grid/app/grid/grid_home/perl/bin/perl -I/grid/app/grid/grid_home/perl/lib -I/grid/app/grid/grid_home/crs/install /grid/app/grid/grid_home/crs/install/rootcrs.pl ' execution failed

[root@crm-db1 ~]#
[main] [ 2018-12-05 02:22:57.058 EST ] [UsmcaLogger.logException:186]  SEVERE:method oracle.sysman.assistants.usmca.backend.USMInstance:configureLocalASM
[main] [ 2018-12-05 02:22:57.058 EST ] [UsmcaLogger.logException:187]  ORA-27504: IPC error creating OSD context
[main] [ 2018-12-05 02:22:57.058 EST ] [UsmcaLogger.logException:188]  oracle.sysman.assistants.util.sqlEngine.SQLFatalErrorException: ORA-27504: IPC error creating OSD context

（左右滑动查看完整代码，下同）

专家解答：

通过对dmp文件仔细检查发现，在执行root.sh时检测到ens3f0:1没有插网线，然后直接报错ORA-27504，非常隐蔽。

可以尝试通过参数_disable_interface_checking = true再执行root.sh

问题二、XD上Oracle用户无法登录

---

问题描述：

Linux上操作系统 就算输入了正确的密码也不能登录 是有哪个配置文件决定？

其他几个节点oracle用户可以正常登录，某个节点oracle不能直接登录，用root改了密码也不行

专家解答：

这种限制默认在exadata上开启的，输错一次密码以后，此用户被锁10分钟；

查看错误次数：

pam_tally2 --user oracle

重置登录错误

pam_tally2 --user oracle --reset

过10分钟以后再登录，并且输入正确的密码。

将/etc/pam.d/sshd 和 /etc/pam.d/login这两个文件中的lock_time条目移除。即将auth required pam_tally2.so deny=5 onerr=fail lock_time=600修改为auth required pam_tally2.so deny=5 onerr=fail

问题三、RAC环境下启动实例报错ORA-01157

---

问题描述：

服务器未知原因故障恢复后，启动数据库实例报错，错误信息如下：

ALTER DATABASE OPEN /* db agent *//* {2:38813:23181} */
This instance was first to open
Fri Mar 01 10:00:41 2019
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\dbw0_5844.trc:
ORA-01157: ????/?????? 11 - ??? DBWR ????
ORA-01110: ???? 11: 'D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\DATABASE\X.DBF'
ORA-27041: ??????
OSD-04002: ÎÞ·¨´ò¿ªÎļþ
O/S-Error: (OS 2) ϵͳÕÒ²»µ½Ö¸¶¨µÄÎļþ¡£
Abort recovery for domain 0

专家解答

从报错看，这个是一个本地数据文件'D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\DATABASE\X.DBF'，应该是你们将RAC中的数据库文件误建到本地磁盘，所以其他实例无法启动，导致错误。

处理方法：

1. 将此数据文件脱机，实例可以马上拉起，然后将此数据文件移动到共享存储，视数据文件大小会有一定时间不能读写；

2. 使用rman copy到共享存储中，脱机做一次switch datafile to copy，不可用读写时间更小。但是完成迁移后实例才能拉起。

问题四、并行查询时禁用直接路径读

---

问题描述：

针对11g以及后面的版本的oracle数据库，设置了_serial_direct_read参数为never，禁用了direct path read，但是加了并行时设置的参数失效了，同样会走direct path read。

我的问题是有没有办法进行控制，让业务语句使用并行，不走direct path read，而是走db file scatt read全表扫描呢？

专家解答：

偶尔走走direct path read也还好，前段时间我们还特意把一个job强置direct path read

ALTER SESSION SET EVENTS '10949 TRACE NAME CONTEXT off';
alter session set events 'trace[NSMTIO] disk=medium';
alter session set "_very_large_object_threshold"=1;
alter session set "_small_table_threshold"=1;
alter session set "_serial_direct_read"=always;
alter session set "_direct_read_decision_statistics_driven"=false;

一般通过设置10949事件，再结合_small_table_threshold、_very_large_object_threshold两个参数就完全禁用直接路径了

问题五、登录失败用户被锁

---

问题描述：

Oracle 11G用户登录失败，数据库大量library cache lock等待事件，随后用户被锁。

问题解答：

这种用户被锁的情况可能由如下3个因素引起：

1. 11G密码延迟验证新特性

在 Oracle 11g 中，为了提升安全性，Oracle 引入了『密码延迟验证』的新特性。这个特性的作用是，如果用户输入了错误的密码尝试登录，那么随着登录错误次数的增加，每次登录前验证的时间也会增加，以此减缓可能对于数据库重复的口令尝试攻击。

但是对于正常的系统，由于口令的更改，可能存在某些被遗漏的客户端，不断重复尝试，从而引起数据库内部长时间的 Library Cache Lock的等待，这种情形非常常见。

如果遇到这一类问题，可以通过Event 28401关闭这个特性，从而消除此类影响，以下命令将修改设置在参数文件中：

ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;

2. 11G登录区分大小写新特性

在11g之前，密码不区分大小写，如果是从之前的老版本升级到11g，可能会遇到这个问题，可以将SEC_CASE_SENSITIVE_LOGON参数修改为FALSE不区分大小写，也可以修改应用的连接密码。

3. 默认登录失败过多锁定账号

用户默认的profile中FAILED_LOGIN_ATTEMPTS为10，也就是用错误密码尝试登陆10次，就会锁定账户，可以通过修改参数避免用户被锁定（有可能存在用错误密码恶意攻击的情况）

alter profile default limit FAILED_LOGIN_ATTEMPTS UNLIMITED;

问题六、删除的分区能够通过Flashback进行闪回吗？

---

问题描述：

通过DROP 删除的分区，能够通过 Flashback Drop 闪回吗？

专家解答：

在Oracle数据库中，单个删除的分区并不会进入回收站，全表删除的分区才可能和全表一起放入回收站。这是因为单个分区删除之后，是无法通过简单的闪回加入原分区表中，既然无法保证一致性，这个分区就不会进入回收站中。

以下这个测试展示了这个过程：

SQL> select * from v$version;
BANNER           CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production   0
PL/SQL Release 12.2.0.1.0 - Production        0
CORE 12.2.0.1.0 Production         0
TNS for Linux: Version 12.2.0.1.0 - Production       0
NLSRTL Version 12.2.0.1.0 - Production        0

SQL> CREATE TABLE enmotech (
2 PartID  integer  not null,
3 CretTm  date  not null,
4 PartCD  varchar2(2) not null
5 ) partition by list (partcd) automatic (
6 partition pBJ values ('BJ'),
7 partition pCD values ('CD'),
8 partition pGZ values ('GZ'),
9 partition pSH values ('SH')
10 );
Table created.

SQL> insert into enmotech values (1, sysdate, 'KM');
1 row created.

SQL> select partition_name from user_tab_partitions
2 where table_name = 'ENMOTECH';
PARTITION_NAME
--------------------------------------------------------------------
PBJ
PCD
PGZ
PSH
SYS_P281

SQL> alter table enmotech drop partition SYS_P281 purge;
alter table enmotech drop partition SYS_P281 purge
*
ERROR at line 1:
ORA-14048: a partition maintenance operation may not be combined with other operations

SQL> alter table enmotech drop partition PSH;
Table altered.

SQL> select * from user_recyclebin;
no rows selected

SQL> drop table enmotech;
Table dropped.

SQL> select object_name,original_name,type from user_recyclebin;
OBJECT_NAME     ORIGINAL_NAME  TYPE
---------------------------------------- -------------------- -------------------------
BIN$TflQLiTmWX7gUwo4qMBX+A==$0   ENMOTECH  TABLE
BIN$TflQLiTmWX7gUwo4qMBX+A==$0   ENMOTECH  Table Partition
BIN$TflQLiTmWX7gUwo4qMBX+A==$0   ENMOTECH  Table Partition
BIN$TflQLiTmWX7gUwo4qMBX+A==$0   ENMOTECH  Table Partition
BIN$TflQLiTmWX7gUwo4qMBX+A==$0   ENMOTECH  Table Partition

很多时候，想当然的结果可能并不可信，实践操作方能出真知，多动手，是技术人的王道。

问题七：ORA-15025:could not open disk unable to open file

---

问题描述：

系统昨天下午5点报ORA-15025 could not open disk和ORA-27041 unable to open file，经排查，是因为/bin/oracle的group不正确导致。

客户的数据库版本是11.2.0.4 for Solairs，半年内没有做过任何改动。

请教大家：没有人为原因，系统未做变化，还有什么情况会导致oracle二进制文件的group发生变化？

问题解答：

这种文件权限变更排除人为因素后，一般都是安装补丁引起。

查看bin/oracle文件上次修改时间为2018年8月17日：

上次打补丁的时间也是这个时间：

Patch  18740837     : 
applied on Fri Aug 17 18:53:49 CST 2018
Unique Patch ID:  20360406   Created on 18 Jul 2016, 18:56:51 hrs UTC   
Bugs fixed:     18740837

所以这个属组应该是打补丁时被修改了，现在才报错的原因可能如下：

1. 新连接才会报错，

2. 通过Oracle用户启动的listener连过来会报错，通过grid用户启动的listener连过来不会报错。

问题八：数据文件处于recover状态ORA-00376

问题描述：

告警日志中出现ORA-00376，查看文件处于ercover状态，请问怎么处理，为什么会出现这样的情况？

ORA-12012: error on auto execute of job 4
ORA-00376: file 1084 cannot be read at this time
ORA-01110: data file 1084: '/dev/vx/rdsk/dg_ora_4adb/vol_ora_4adb_dev1089' 
--datafile in recover mode
sys >select name,status from v$datafile where name like '/dev/vx/rdsk/dg_ora_4adb/vol_ora_4adb_dev108%';
NAME                                            STATUS
----------------------------------------------- -------
/dev/vx/rdsk/dg_ora_4adb/vol_ora_4adb_dev1089   RECOVER

专家解答：

直接recover并online数据文件即可：

sys >recover datafile 1084;Media recovery complete.sys >select name,status  from v$datafile where ts#=1;NAME-------------------------------------STATUS-------/dev/vx/rdsk/dg_ora_4adb/vol_ora_4adb_dev1089OFFLINE sys >alter database datafile 1084 online;Database altered. sys >select name,status  from v$datafile where ts#=1;NAME                                                                             STATUS-------------------------------------------------------------------------------- -------/dev/vx/rdsk/dg_ora_4adb/vol_ora_4adb_dev1089                                    ONLINE

另外，关于数据文件处于recover模式的原因一般有以下几种：

1. 不正确的方式打开数据文件，或者突然关闭数据文件

2. 操作系统故障

3. 由于病毒、恶意软件、人为因素导致

4. 硬件故障、软件bug导致数据文件损坏

5. 数据库打开时网络突然断开或者中断

想看更多精彩问答，欢迎关注“DBASK”小程序，你也有机会成为专家团的一员！

---

资源下载

关注公众号：数据和云（OraNews）回复关键字获取

2018DTCC ，数据库大会PPT

2018DTC，2018 DTC 大会 PPT

ENMOBK，《Oracle性能优化与诊断案例》

DBALIFE ，“DBA 的一天”海报

DBA04 ，DBA 手记4 电子书

122ARCH ，Oracle 12.2体系结构图

2018OOW ，Oracle OpenWorld 资料

云和恩墨大讲堂 | 一个分享交流的地方

长按，识别二维码，加入万人交流社群

请备注：云和恩墨大讲堂