共计 2667 个字符，预计需要花费 7 分钟才能阅读完成。
引言
近期我们在 DBASK 小程序新关联了韩锋频道、互联网侦察、数据库 SQL、SQL 数据库开发、跨界架构师、石杉的架构笔记等数据领域的公众号，聚合更新展示，欢迎大家阅读分享。
问答集萃
接下来，我们分享本期整理出的问题和诊断总结，供大家参考学习，详细的诊断分析过程可以通过标题链接跳转到小程序中查看。
问题一、Windows 系统是否需要设置 filesystemio_options
如题，数据版本为 10g
诊断结论：不需要设置，参考《Best Practices For Oracle Database Performance On Windows》
问题二、windows 安装 oracle dbca 建库报错 ora-27102 out of memory
windows 2016(64bit) 安装 oracle 11g r2 (64bit) dbca 建库报错 ora-27102 out of memory，windows 系统内存 64G 分配给 oracle 内存 24G 空闲内存充足，这个是因为 2016 系统有啥限制吗该如何解决？
诊断结论：问题为 window 操作系统参数的问题。在控制面板中将处理器核数由默认的 1 改成 8 或最大值即可，重新启动，然后再 dbca 建库. 成功。
问题三、集群资源 ora.LISTENER_LEAF.lsnr, 资源 offline, 这是什么资源？
集群资源 ora.LISTENER_LEAF.lsnr, 资源 offline。db 版本 12.2.0.1。
诊断结论：这是 12c Oracle Flex Cluster 的特性，引入了叶子节点的概念，不需要直接连接共享存储。而 LISTENER_LEAF 是用来注册 leaf node 上运行的实例的。
问题四、Execute to Parse % 指标 24.95，硬解析比例很高
数据库中，Execute to Parse % 指标 24.95，SQL 硬解析比例很低，排除 cursor_sharing= force，系统负载非常低,AWR 采样时间 60 分钟，db time1mins。
希望获取 SQL 能找到造成大量硬解析的 SQL 文本，或者应用连接 mode，
获取降低硬解析的方法。
** 诊断结论：一般来说硬解析高的 SQL 主要的原因就是没有使用绑定变量，其次就是内存不够或者 BUG 等原因了。
可以使用详情中的 SQL 查出没有使用绑定变量的 SQL。**
问题五、Asm 磁盘组冗余模式 IO 性能有差异么
Asm 磁盘组冗余模式，IO 性能有差异么？差异有多大？
** 诊断结论：在读场景下，不论冗余方式，都只读其中一份 AU，所以不会有读性能的损失。
在写的场景下，外部冗余的 ASM 磁盘组的 IO 性能，可以近似理解为是所有 LUN 的 IO 综合，包括 IOPS 及吞吐量。Normal 冗余是双写嘛，因为每次要写两个相同的 AU，所以可以理解为 IO 相关指标损失一半。High 冗余损失三分之二。**
问题六、ogg 12c 可以应用源为 10g 的 trail 文件吗？
如题，10g 的 trail 文件是否可以应用到 12c 中，需要注意什么？
诊断结论：应该是没问题，建议测试验证下。源端抽取进程和传输进程加下参数 FORMAT RELEASE。另外目标端需要非 PDB 模式。
问题七、删除一张上亿记录数表的唯一性约束和索引有什么影响
如题，删除了一张记录数有一亿的表的唯一性约束和索引，会有影响么？重建会花多久？
诊断结论：删除本身当然没有影响。只不过数据完整性没法保证，索引无法利用。至于创建时间要根据表大小，当前业务量，系统 i / o 情况，需要全扫表读取数据，然后内存排序创建唯一索引。可以看下 session_longops，或者根据索引的段大小推测所需时间。
问题八、TB 级别数据库搭建 goldengate
在这个级别搭建 ogg 使用 table 还是 schema 进行？？，在后期表结构会发生变化的情况下哪种方式方便后期维护？
诊断结论：如果非要用 OGG，建议按表拆分多个进程吧，不然一个进程出现问题会影响整个库的同步。
问题九、oracle rac 时间被调整的影响
rac 配置了时钟同步，由于时钟同步服务器出问题导致 rac 两个节点时间被同时调整到了 3 天后，然后关闭集群手动调整系统时间，启动集群后发现 undo 的 begintime 和快照时间都有问题，目前重建了 undo，这种事故对数据库有其他影响嘛？？业务数据问题已与研发沟通过，没造成影响
** 专家解答：如果业务数据确认没有问题，数据库能正常启动运行的话问题不大，依赖时间戳的主要是日志和监控数据类，建议重要的检查处理下:
1、grid/db 的相关 alertlog 备份清理下问题的日志
2、AWR 备份删除部分 snapshot，以免混淆
3、sys.WRH$_ACTIVE_SESSION_HISTORY 的相关记录 **
问题十、Oracle Stream 不再被支持了吗？从什么版本开始的？
之前的旧系统，有些还在使用 Stream 流复制，听说不被 Oracle 支持了。将来要怎么办？
** 诊断结论：Oracle Streams 在 Oracle Database 12c 第 1 版（12.1）中已弃用。不支持 Oracle Database 12c 及更高版本中引入的支持功能，包括多租户架构，LONG VARCHAR 数据类型，长标识符和其他功能。
Oracle Database 18c 是 Oracle Streams 支持的最终版本。从 Oracle Database 19c 开始，Oracle Streams 将不再受支持。
对于复制来说，Oracle GoldenGate 是 Oracle 数据库复制的最终解决方案。**
问题十一、ASM 新加 DG，数据文件如何迁移
oracle12c 数据库原来创建的表空间所在 asm 上的 DG 用完，我又新加了一个 DG 如何修改原来 DG 上表空间的参数设置，比如表空间自动扩展
诊断结论：关闭之前 DG 上所有数据文件的自动扩展，然后在新 DG 上为相应表空间创建数据文件即可。还有 temp、undo 这些方便迁移的，可以移到新的 DG 上。
问题十二、关于 Extended RAC 两种模式压测存储复制的方式都优于 ASM 冗余
我们正在实施容灾项目，对比 Extended RAC 在存储复制和 ASM 冗余两种方案的性能，供客户方案选型，目前测试的结果显示存储复制的方式都优于 ASM 冗余的方式。请问测试结果符合预期吗如何理解这种结果？
诊断结论：我认为应该是符合预期的。存储复制层面会有比较多的额外硬件支持，比如 cache，比如硬件级别的 IO 复制优化。而这些都是单纯的 ASM 多副本写出所不具备的。毕竟存储级复制产品作为一个商业产品要卖出价格，必须要有更值得付钱的功能。
想了解更多知识问答吗？登录“墨天轮”马上学习！
