20万DBA都在关注的12个问题
引言
近期我们在DBASK小程序新关联了韩锋频道、互联网侦察、数据库SQL、SQL数据库开发、跨界架构师、石杉的架构笔记等数据领域的公众号，聚合更新展示，欢迎大家阅读分享。
问答集萃
接下来，我们分享本期整理出的问题和诊断总结，供大家参考学习，详细的诊断分析过程可以通过标题链接跳转到小程序中查看。
如题，数据版本为10g
诊断结论：不需要设置，参考《Best Practices For Oracle Database Performance On Windows》
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。db版本12.2.0.1。
诊断结论：这是12c Oracle Flex Cluster的特性，引入了叶子节点的概念，不需要直接连接共享存储。而LISTENER_LEAF是用来注册leaf node上运行的实例的。
数据库中，Execute to Parse %指标24.95，SQL硬解析比例很低，排除cursor_sharing= force，系统负载非常低,AWR采样时间60分钟，db time1mins。
希望获取SQL能找到造成大量硬解析的SQL文本，或者应用连接mode，
获取降低硬解析的方法。
诊断结论：一般来说硬解析高的SQL主要的原因就是没有使用绑定变量，其次就是内存不够或者BUG等原因了。
可以使用详情中的SQL查出没有使用绑定变量的SQL。
Asm磁盘组冗余模式，IO性能有差异么？差异有多大？
诊断结论：在读场景下，不论冗余方式，都只读其中一份AU，所以不会有读性能的损失。
在写的场景下，外部冗余的ASM磁盘组的IO性能，可以近似理解为是所有LUN的IO综合，包括IOPS及吞吐量。Normal冗余是双写嘛，因为每次要写两个相同的AU，所以可以理解为IO相关指标损失一半。High冗余损失三分之二。
如题，10g的trail文件是否可以应用到12c中，需要注意什么？
诊断结论：应该是没问题，建议测试验证下。源端抽取进程和传输进程加下参数FORMAT RELEASE。另外目标端需要非PDB模式。
如题，删除了一张记录数有一亿的表的唯一性约束和索引，会有影响么？重建会花多久？
诊断结论：删除本身当然没有影响。只不过数据完整性没法保证，索引无法利用。至于创建时间要根据表大小，当前业务量，系统i/o情况，需要全扫表读取数据，然后内存排序创建唯一索引。可以看下session_longops，或者根据索引的段大小推测所需时间。
在这个级别搭建ogg使用table还是schema进行？？，在后期表结构会发生变化的情况下哪种方式方便后期维护？
诊断结论：如果非要用OGG，建议按表拆分多个进程吧，不然一个进程出现问题会影响整个库的同步。
rac配置了时钟同步，由于时钟同步服务器出问题导致rac两个节点时间被同时调整到了3天后，然后关闭集群手动调整系统时间，启动集群后发现undo的begintime和快照时间都有问题，目前重建了undo，这种事故对数据库有其他影响嘛？？业务数据问题已与研发沟通过，没造成影响
专家解答：如果业务数据确认没有问题，数据库能正常启动运行的话问题不大，依赖时间戳的主要是日志和监控数据类，建议重要的检查处理下:
1. grid/db的相关alertlog备份清理下问题的日志
2. AWR备份删除部分snapshot，以免混淆
3. sys.WRH$_ACTIVE_SESSION_HISTORY的相关记录
之前的旧系统，有些还在使用 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数据库复制的最终解决方案。
oracle12c数据库原来创建的表空间所在asm上的DG用完，我又新加了一个DG如何修改原来DG上表空间的参数设置，比如表空间自动扩展
诊断结论：关闭之前DG上所有数据文件的自动扩展，然后在新DG上为相应表空间创建数据文件即可。还有temp、undo这些方便迁移的，可以移到新的DG上。
我们正在实施容灾项目，对比Extended RAC在存储复制和ASM冗余两种方案的性能，供客户方案选型，目前测试的结果显示存储复制的方式都优于ASM冗余的方式。请问测试结果符合预期吗如何理解这种结果？
诊断结论：我认为应该是符合预期的。存储复制层面会有比较多的额外硬件支持，比如cache，比如硬件级别的IO复制优化。而这些都是单纯的ASM多副本写出所不具备的。毕竟存储级复制产品作为一个商业产品要卖出价格，必须要有更值得付钱的功能。
出处：墨天轮（ID：enmocs）
扩展阅读
数据和云
ID：OraNews
如有收获，请划至底部，点击“在看”，谢谢！
公司简介 | 招聘 | DTCC | 数据技术嘉年华 | 免费课程 | 入驻华为严选商城
zCloud | SQM | Bethune Pro2 | zData一体机 | MyData一体机 | ZDBM 备份一体机
Oracle技术架构 | 免费课程 | 数据库排行榜 | DBASK问题集萃 | 技术通讯
升级迁移 | 性能优化 | 智能整合 | 安全保障 | 架构设计 | SQL审核 | 分布式架构 | 高可用容灾 | 运维代维
云和恩墨大讲堂 | 一个分享交流的地方
长按，识别二维码，加入万人交流社群
请备注：云和恩墨大讲堂